Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jan 5, 2024 at 11:53 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
I think it'd be quite simple. As I said, it's just a small variation
on how some GUCs already work. The only thing that's really
transactional is SQL-driven updates, which'd be disallowed for this
class of variables.
(After consuming a little more caffeine, I wonder if the class ought
to be defined by a new PGC_XXX context value, rather than a flag bit.)
regards, tom lane
