public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Narek Galstyan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
Date: Thu, 13 Jun 2024 15:39:30 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com>
References: <CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com>

Narek Galstyan <[email protected]> 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

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox