On Thu, Jul 11, 2019 at 10:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> All of the above is based on the assumption that this isn't a plain
> old USERSET GUC, which I'm not really seeing the argument for.
> OK, there might be *implementation* reasons why we would rather not
> deal with on-the-fly changes to the list, but there's no advantage
> to users in it.
It's pretty important that this value remain fixed for the lifetime of
a session. If it can be changed during the session via SQL, or via
SET commands attached to a function for example, then driver authors
can't count on it to really be set to the value that they requested.
Also, think about something like a connection pooler. The user might
request one list of GUCs from the driver, and the driver might request
a different (probably larger) from the connection pooler, and the
connection pooler might then request a different (and presumably still
larger) list of GUCs from the server. If the end-user can shoot a SET
command through and change the setting on the server, the connection
pooler and the driver will break, because they were presumably
counting on getting the reports for which they asked (and forwarding
the ones someone else asked).
We have steadfastly refused to provide protocol-level tools for things
like "please change my user ID, and don't let anyone change it again
via SQL," and that's a huge problem for things like connection poolers
which can't parse all the SQL flowing through the connection (because
figuring out what it does requires solving the Halting Problem) and
wouldn't want to if they could for performance reasons. I think that's
a huge mistake. The FEBE protocol endpoint is not the application, but
some intermediate piece of software that needs control over its own
destiny. Even when there is no pooling involved, the FEBE endpoint is
the driver, not the application. That distinction is subtle, but it is
real, and it matters here too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
