From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | shihao zhong <zhong950419(at)gmail(dot)com> |
Cc: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, gavinpanella(at)gmail(dot)com |
Subject: | Re: Allow ALTER SYSTEM SET on unrecognized custom GUCs |
Date: | 2023-10-19 16:00:21 |
Message-ID: | 3358121.1697731221@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
shihao zhong <zhong950419(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-10-19 16:01:40 | Re: [PATCH] Add support function for containment operators |
Previous Message | Tom Lane | 2023-10-19 15:31:58 | Re: boolin comment not moved when code was refactored |