From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Hayden Sim <haydenwillsim(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name |
Date: | 2024-07-19 13:17:19 |
Message-ID: | CAKFQuwZoeyHEcN0UAy59FZp91DeM=VAFR3h=UbYjs5D0fvBYzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thursday, July 18, 2024, Hayden Sim <haydenwillsim(at)gmail(dot)com> wrote:
> I understand it is a side effect of SET causing the custom GUC to be
> initialised. But the behaviour of `SET LOCAL` affecting the entire session,
> even outside of the transaction seems bizarre. Should exiting the
> transaction or calling `SET ... TO DEFAULT` not cause the parameter to be
> deleted?
>
Yes, it is a POLA violation. But there is no interest in fixing this,
especially not as a bug fix. I suggest you instead support the commitfest
patch to get proper variables into PostgreSQL.
To reiterate, it is a bug in client code to rely on NULL being a setting
value (i.e., we made a mistake in providing a current setting function that
produces null instead of an error.).
There is pending documentation, that probably either needs tweaks or could
be modified to update different areas, in light of this discussion
(touching current_setting seems warranted) to add this behavior more
prominently to the docs. Reviewing that would also help.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-07-19 14:44:19 | Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends |
Previous Message | PG Bug reporting form | 2024-07-19 09:25:11 | BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION |