Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
Subject: Re: set_config with is_local parameter true escapes transaction
 boundaries
From: Ruslan Talpa <ruslan.talpa@subzero.cloud>
In-Reply-To: <392925.1673397546@sss.pgh.pa.us>
Date: Wed, 11 Jan 2023 08:54:25 +0200
Cc: pgsql-bugs@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <17634C6E-1208-4254-A82F-9B9AEEC2DCA9@subzero.cloud>
References: <997A11B3-BC14-44FB-A505-BE7C49BE5330@subzero.cloud>
 <392925.1673397546@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/17634C6E-1208-4254-A82F-9B9AEEC2DCA9%40subzero.cloud>
Precedence: bulk

It=E2=80=99s true that null is not a valid value for GUC however the =
infrastructure does make a distinction between =E2=80=9Cthe setting has =
no value, as in empty string=E2=80=9D and =E2=80=9Cthere is no such =
setting, null=E2=80=9D and since the documentation for set_config only =
says =E2=80=9CIf is_local is true, the new value will only apply during =
the current transaction.=E2=80=9D 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 =E2=80=9CNote: Once a GUC value has been =
set, even with is_local set to true, subsequent calls to current_setting =
will return an empty string=E2=80=9D

In any case, I am only reporting (what I view as) an inconsistency i =
came across that is not mentioned anywhere and thought I=E2=80=99d 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=E2=80=99s clear that this infrastructure was designed for =
PG extensions to use, however currently it=E2=80=99s being (ab)used by =
popular tools like PostgREST/Postgraphile/Hasura as a =E2=80=9Ctransaction=
 context=E2=80=9D, i.e. store within a transaction things like =E2=80=9Cwh=
o is executing the current query=E2=80=9D or =E2=80=9Cfrom what ip=E2=80=9D=
 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 =
=E2=80=9Cthat context value is not set=E2=80=9D and =E2=80=9Cthat =
context value is an empty string=E2=80=9D or at least be aware this =
issue exists.


> On 11 Jan 2023, at 02:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Ruslan Talpa <ruslan.talpa@subzero.cloud> writes:
>> When executing set_config with the parameter =E2=80=98is_local=E2=80=99=
 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
>=20
> The GUC infrastructure doesn't recognize null as a value, so you
> are making a distinction that the system doesn't.
>=20
> regards, tom lane