On Fri, Jan 5, 2024 at 11:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > There is a lot of infrastructure we'll have to re-invent if > we make this completely independent of GUCs, notably: > * a way to establish the initial/default value > * a way to display the active value > > So my thought was that this should be implemented as an (unchangeable) > flag bit for a GUC variable, GUC_PROTOCOL_ONLY or something like that, > and then we would refuse SQL-based set attempts on that. The behavior > would end up being very much like PGC_BACKEND variables, in that we > could allow all the existing setting methods to work to establish > a session's initial value; but after that, it can only change within > that session via a protocol message from the client. With that > rule, it's okay for the protocol message to be nontransactional since > there's no interaction with transactions.
Maybe, but it seems like it might be complicated to make that work with the existing GUC code. GUCs are fundamentally transactional, I think. -- Robert Haas EDB: http://www.enterprisedb.com
