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 CAKFQuwZ=uvUXs2uOc3z5wvJK-2BEotEhc-2P6jFwAnR1=KCDRg@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:
Hi,

I think the most confusing part is the documentation saying:
"""
DEFAULT can be written to specify resetting the parameter to its
default value (that is, whatever value it would have had if no SET had
been executed in the current session).
"""

It would be expected that subsequent calls to `current_setting()` should throw an error (without the "t" parameter.) As would have been the case if `SET` hadn't ever been executed in the session. This is increasingly confusing when a call to `SET LOCAL "foo.bar" TO 'baz';` runs inside a transaction, as this will affect behaviour outside of the transaction. As can be seen here:

I need to review exactly what I changed but my Document NULL patch in the commitfest does cover this behavior.  In short you cannot rely on either the error or NULL to represent unknown/unset.  The system was not designed to allow settings that were not externally defined to the session to be used.  If externally defined every setting both exists and has a non-null value.

David J.
 

pgsql-bugs by date:

Previous
From: Hayden Sim
Date:
Subject: Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name
Next
From: Tom Lane
Date:
Subject: Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name