On Mon, Oct 9, 2023 at 5:02 PM Jelte Fennema <postgres@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
