On Thu, Jul 11, 2019 at 10:35 AM Tom Lane <t...@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
