Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs - Mailing list pgsql-hackers

From shihao zhong
Subject Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs
Date
Msg-id CAGRkXqTLECtkJ_LcQb7YLzddm8dgbLedUA4bOq5h+4_AQkiVyQ@mail.gmail.com
Whole thread Raw
In response to Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thanks for the answer. The code looks good to me.

Thanks,
Shihao

On Thu, Oct 19, 2023 at 12:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
shihao zhong <zhong950419@gmail.com> writes:
> I do like the idea that we should keep the set and the altar system with
> the same behavior. But one thing I am worried about is the typo detected
> here because I usually make that type of mistake myself. I believe we
> should have an extra log to explicitly tell the user this is a `custom
> variable` guc.

I don't think there's any chance of getting away with that.  As noted
upthread, a lot of people use placeholder GUCs as a substitute for a
proper session-variable feature.  If we ever get real session variables,
we could start to nudge people away from using placeholders; but right
now too many people would complain about the noise of a warning.

> Btw, another aspect I want to better understand is if the superuser session
> called pg_reload_conf with custom variables, does that mean these custom
> variables will override the other active transaction's SET command?

No, a per-session SET will override a value coming from the config file.
That's independent of whether it's a regular or custom GUC.

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: trying again to get incremental backup
Next
From: David Steele
Date:
Subject: Re: The danger of deleting backup_label