public inbox for [email protected]
help / color / mirror / Atom feedRe: RESET, NULL and empty-string valued settings and transaction isolation
2+ messages / 2 participants
[nested] [flat]
* Re: RESET, NULL and empty-string valued settings and transaction isolation
@ 2024-10-19 15:07 Tom Lane <[email protected]>
2024-10-19 17:27 ` Re: RESET, NULL and empty-string valued settings and transaction isolation Marcelo Zabani <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Tom Lane @ 2024-10-19 15:07 UTC (permalink / raw)
To: Marcelo Zabani <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]>
Marcelo Zabani <[email protected]> writes:
> Hi, according to the docs, RESET sets the value of a setting to
> "The default value is defined as the value that the parameter would have
> had, if no SET had ever been issued for it in the current session"
This is, I guess, strictly true only for built-in settings.
Custom settings act a little differently in that they don't
exist at all before you assign to them. Thus
> $ psql
> => select current_setting('my.test', true) is null; -- true
my.test doesn't exist here. current_setting(..., true) returns NULL
instead of throwing an error, although SHOW reacts differently:
regression=# show my.test;
ERROR: unrecognized configuration parameter "my.test"
> => set my.test = 'abc';
> => reset my.test;
Now it does exist, but its reset value is an empty string.
> => select current_setting('my.test', true) is null; -- false
> => select current_setting('my.test', true)=''; -- true
> Is this expected? I thought even if I misunderstand the docs, the effect
> isn't very nice because SQL like
> current_setting('my.some_boolean_setting')::boolean will fail after a
> transaction with SET LOCAL sets it, a side-effect that can be particularly
> confusing and basically requires usage of nullif(.., '') or other explicit
> checks around every current_setting call-site in practice.
[ shrug... ] This whole area is an undocumented, unsupported abuse
of a behavior that's only meant to support GUCs defined by loadable
extensions. (To wit, allowing postgresql.conf to set values for
GUCs that aren't loaded yet.) Without a way to declare a GUC's type,
reset value, etc, there's no way to have custom GUCs act really
consistently with built-in ones.
Pavel Stehule has spent years pushing forward a patch to invent
a better-thought-out implementation of custom session variables [1].
Every time I look at it, I come away with the feeling that it's
a giant patch with a much smaller patch struggling to get out.
But certainly the area needs some nontrivial thought, and I'm not
sure that extending the GUC mechanism is a better answer.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/CAFj8pRD053CY_N4%3D6SvPe7ke6xPbh%3DK50LUAOwjC3jm8Me9Obg%4...
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: RESET, NULL and empty-string valued settings and transaction isolation
2024-10-19 15:07 Re: RESET, NULL and empty-string valued settings and transaction isolation Tom Lane <[email protected]>
@ 2024-10-19 17:27 ` Marcelo Zabani <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Marcelo Zabani @ 2024-10-19 17:27 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-generallists.postgresql.org <[email protected]>
Thank you both for the explanations and the link to the discussion of
Pavel's patches.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-10-19 17:27 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-10-19 15:07 Re: RESET, NULL and empty-string valued settings and transaction isolation Tom Lane <[email protected]>
2024-10-19 17:27 ` Marcelo Zabani <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox