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.
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? Thanks, Shihao On Wed, Oct 18, 2023 at 1:59 AM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > On 18/10/2023 12:15, Tom Lane wrote: > > Andrei Lepikhov <a.lepik...@postgrespro.ru> writes: > >> "SET foo.bar TO 'smth'" can immediately alter the placeholder's value. > >> But what is the reason that "ALTER SYSTEM SET foo.bar TO 'smth'" doesn't > >> do the same? > > > > Because it's not supposed to take effect until you issue a reload > > command (and maybe not even then, depending on which GUC we're > > talking about). I certainly think it wouldn't make sense for your > > own session to adopt the value ahead of others. > > Thanks for the answer. > Introducing the assignable_custom_variable_name can be helpful. The code > looks good. I think it deserves to be committed - after the indentation > fix, of course. > > -- > regards, > Andrey Lepikhov > Postgres Professional > > > >
