Re: set_config with is_local parameter true escapes transaction boundaries

It’s true that null is not a valid value for GUC however the infrastructure does make a distinction between “the setting has no value, as in empty string” and “there is no such setting, null” and since the documentation for set_config only says “If is_local is true, the new value will only apply during the current transaction.” the expectation is that after the transaction things should return to the previous state (i.e current_setting should return null)

Maybe this is only a documentation issue, for example have a note in 9.27.1 or 20.16 along the lines “Note: Once a GUC value has been set, even with is_local set to true, subsequent calls to current_setting will return an empty string”

In any case, I am only reporting (what I view as) an inconsistency i came across that is not mentioned anywhere and thought I’d bring it up so that PG developers are aware can make a decision either way.

Thank you for your work (and reply to the email)

PS: A few more words about the context where this came up, feel free to skip this.
Per 20.16 it’s clear that this infrastructure was designed for PG extensions to use, however currently it’s being (ab)used by popular tools like PostgREST/Postgraphile/Hasura as a “transaction context”, i.e. store within a transaction things like “who is executing the current query” or “from what ip” so that code from the database context (triggers/views/stored procedures) can act based on that information. Looking at it from this use case point of view, one would want to make a distinction between “that context value is not set” and “that context value is an empty string” or at least be aware this issue exists.

> On 11 Jan 2023, at 02:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Ruslan Talpa <ruslan(dot)talpa(at)subzero(dot)cloud> writes:
>> When executing set_config with the parameter ‘is_local’ set to true within a transaction, it is expected that the config value is not available after the transaction however once the config is set in any transaction, current_setting will return an empty string instead of null
>
> The GUC infrastructure doesn't recognize null as a value, so you
> are making a distinction that the system doesn't.
>
> regards, tom lane