Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name
Date
Msg-id CAKFQuwZoeyHEcN0UAy59FZp91DeM=VAFR3h=UbYjs5D0fvBYzg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name  (Hayden Sim <haydenwillsim@gmail.com>)
List pgsql-bugs
On Thursday, July 18, 2024, Hayden Sim <haydenwillsim@gmail.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.

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION
Next
From: Nathan Bossart
Date:
Subject: Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends