From: Tom Lane <tgl@sss.pgh.pa.us>
To: Narek Galstyan <narekg@berkeley.edu>
cc: pgsql-general@lists.postgresql.org, narek@lantern.dev
Subject: Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
In-reply-to: <CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com>
References: <CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com>
Comments: In-reply-to Narek Galstyan <narekg@berkeley.edu>
	message dated "Thu, 13 Jun 2024 12:26:00 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2074488.1718307570.1@sss.pgh.pa.us>
Date: Thu, 13 Jun 2024 15:39:30 -0400
Message-ID: <2074489.1718307570@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2074489.1718307570%40sss.pgh.pa.us>
Precedence: bulk

Narek Galstyan <narekg@berkeley.edu> writes:
> 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.

No, but a warning will be reported when the extension does get loaded.

This seems in line to me with the general behavior of
extension-defined GUCs: we cannot know anything about whether a value
stored in the config file is sane until we have loaded the extension
that defines the GUC's data type, allowed range, etc.

> I'd expect GUC variables reserved by an extension to live more permanently
> in Postgres catalogs (e.g., in pg_settings).

How would they get there?  What happens when the extension goes away?
How would such an approach emulate C-code-enforced restrictions,
that is checks made by a GUC check_hook?  What happens if different
databases in an installation have inconsistent catalog entries for
a GUC?  (You could eliminate such inconsistency by storing the data
in a shared catalog, perhaps, but that brings some other concerns.)

I don't really see the value for work expended here.

			regards, tom lane