Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name

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.

In response to

Browse pgsql-bugs by date

  From Date Subject
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