Jelte Fennema-Nio
Jelte Fennema-Nio
No, it's blocked on me finding some time to review PgBouncer PRs again. Busy busy.
I don't remember why I didn't press merge yet, maybe because CI was failing for unrelated reasons.
I think this is something that we'll eventually want to support. But I think it should be built on top of the logic that we're implementing in #477. In #477...
Thanks for the bug report. That's indeed something we should fix. However, the usage of prepared statements at the SQL level (i.e. PREPARE/EXECUTE queries) is a lot lower than at...
I pushed a change that I think should fix these docker build steps on PRs.
Isn't the search_path problem an issue with pgbouncer=true as well? In any case it seems rather unrelated to prepared statements. BTW, it is supported if you use PgBouncer together with...
I guess part of my question was not clear: how does pgbouncer=true make ?schema=foo work? Does it start qualifying every table? Also working around the search_path issue is fairly simple...
> Ah, understood: `pgbouncer=true` makes Prisma skip the `SET search_path = ...` query basically only. We qualify tables by default - except for user-provided raw queries, which might not work...
So, that error definitely means somehow pgbouncer thinks a query is prepared on the server connection, but somehow it isn't. Are you sure there are no clients at all using...
> In order to not have downtime and or have to do a full server swap deploy, ideally Prisma would support the new version of pgbouncer with or without `pgbouncer=true`,...