MIME-Version: 1.0
From: Narek Galstyan <narekg@berkeley.edu>
Date: Thu, 13 Jun 2024 12:26:00 -0700
Message-ID: <CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com>
Subject: Reserving GUC prefixes from a non-preloaded DB extension is not
 always enforced
To: pgsql-general@lists.postgresql.org
Cc: narek@lantern.dev
Content-Type: multipart/alternative; boundary="000000000000b6cb52061aca78fd"
Archived-At: <https://www.postgresql.org/message-id/CANdDwNJ0ab56KuvRSGBL_ZAnTs%3D_%3DHzu9kdO%3De2DB-dwtTTU0w%40mail.gmail.com>
Precedence: bulk

--000000000000b6cb52061aca78fd
Content-Type: text/plain; charset="UTF-8"

Hi all,

I am an extension developer. I use `MarkGUCPrefixReserved` to reserve GUC
prefixes, which my extension uses to help avoid accidentally misspelled
config-file entries.

However, since the reservation happens in `_PG_init()` and `_PG_init()` is
not called until the first use of an API exposed by my extension,
misspelled config-file entries that get executed before the extension is
loaded will not throw an error.

SET lantern.haha = 1; -- succeeds, since lantern extension is not loaded

SELECT ARRAY[1] <-> ARRAY[1]; -- uses a lantern API, so extension binary is
loaded
-- The line above does warn about removing the configuration parameter above
-- WARNING:  invalid configuration parameter name "lantern.haha", removing
it
-- DETAIL:  "lantern" is now a reserved prefix.

 SET lantern.haha = 1; -- now this throws an error
-- ERROR:  invalid configuration parameter name "lantern.haha"
-- DETAIL:  "lantern" is a reserved prefix.

I think, ideally, the last error should be thrown in the first SET
execution as well.

I'd expect GUC variables reserved by an extension to live more permanently
in Postgres catalogs (e.g., in pg_settings).
So, even when the extension binary is not loaded, Postgres would know which
prefixes are reserved and which GUC settings must be allowed (similar to
how Postgres knows in pg_extension which extensions are enabled, even when
the corresponding extension binary has not been loaded).

1. Would you consider the proposed behavior an improvement?

2. If so, do you have thoughts on how to implement it?

Thanks!
Narek Galstyan
--

--000000000000b6cb52061aca78fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I am an extension developer. I =
use `MarkGUCPrefixReserved` to reserve GUC prefixes, which my extension use=
s to help avoid accidentally misspelled config-file entries.</div><div><br>=
</div><div>However, since the reservation happens in `_PG_init()` and `_PG_=
init()` is not called until the first use of an API exposed by my extension=
, misspelled config-file entries that get executed before the extension is =
loaded will not throw an error.</div><div><br></div><div>SET lantern.haha =
=3D 1; -- succeeds, since lantern=C2=A0extension is not loaded<br></div><di=
v><br></div><div>SELECT ARRAY[1] &lt;-&gt; ARRAY[1]; -- uses a lantern API,=
 so extension binary is loaded<br></div><div>-- The line above does warn ab=
out removing the configuration parameter above</div><div>-- WARNING: =C2=A0=
invalid configuration parameter name &quot;lantern.haha&quot;, removing it<=
br>-- DETAIL: =C2=A0&quot;lantern&quot; is now a reserved prefix.<br></div>=
<div><br></div><div>=C2=A0SET lantern.haha =3D 1; -- now this throws an err=
or<br>-- ERROR: =C2=A0invalid configuration parameter name &quot;lantern.ha=
ha&quot;<br>-- DETAIL: =C2=A0&quot;lantern&quot; is a reserved prefix.<br><=
/div><div><br></div><div>I think, ideally, the last error should be thrown =
in the first SET execution as well.</div><div><br></div><div>I&#39;d expect=
 GUC variables reserved by an extension to live more permanently in Postgre=
s catalogs (e.g., in pg_settings).=C2=A0</div><div>So, even when the extens=
ion binary is not loaded, Postgres would know which prefixes are reserved a=
nd which GUC settings must be allowed (similar to how Postgres knows in pg_=
extension which extensions are enabled, even when the corresponding extensi=
on binary has not been loaded).</div><div><br></div><div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px"><div>1. Would you consider t=
he proposed behavior an improvement?</div></blockquote><blockquote style=3D=
"margin:0 0 0 40px;border:none;padding:0px"><div>2. If so, do you have thou=
ghts on how to implement it?</div><div><br></div></blockquote></div><div>Th=
anks!</div><div>Narek Galstyan</div><div>--</div><div><br></div></div>

--000000000000b6cb52061aca78fd--