On Mon, Oct 9, 2023 at 5:02 PM Jelte Fennema <postg...@jeltef.nl> wrote: > Honestly I think the main difference is the need to introduce this > explicit protocol message. If we do, I think it might be best to have > this be a way of setting a GUC at the Protocol level, and expand the > GucContext enum to have a way to disallow setting it from SQL (e.g. > PGC_PROTOCOL), while still allowing PgBouncer (or other poolers) to > change the GUC as part of the connection handoff, in a way that's > similar to what's being done for client_encoding now. We might even > want to make client_encoding PGC_PROTOCOL too (eventually).
That's an idea worth considering, IMHO. I'm not saying it's the best or only idea, but it seems to have some real advantages. The pooler case is actually a really important one here. If the client is connected directly to the server, the difference between whether something is controlled via the protocol or via SQL is just whether it could be set inside some function. I think that's a thing to be concerned about, but when you add the pooler to the equation then you have the additional question of whether a certain value should be controlled by the end-client or by the pooler. A really obvious example of where you might want the latter behavior is session_authorization. You'd like the pooler to be able to set that in such a way that the end-client can't tinker with it by any means. Right now we don't have a way to do that, but maybe someday we will. This issue is perhaps a bit less critical, but it still feels bad if the end-client can effectively pull the rug out from under the pooler's wire protocol expectations. I'm not exactly sure what the right policy is here concretely, so I'm not ready to argue for exactly what we should do just yet, but I do want to argue that we should be thinking carefully about these issues. -- Robert Haas EDB: http://www.enterprisedb.com