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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name
Дата
Msg-id CAKFQuwZ=uvUXs2uOc3z5wvJK-2BEotEhc-2P6jFwAnR1=KCDRg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name  (Hayden Sim <haydenwillsim@gmail.com>)
Список 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 по дате отправления: