public inbox for [email protected]  

help / color / mirror / Atom feed

From: Laurenz Albe <[email protected]>
To: Narek Galstyan <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
Date: Fri, 14 Jun 2024 09:44:57 +0200
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>

On Thu, 2024-06-13 at 12:26 -0700, Narek Galstyan wrote:
> 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.
> 
> 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?

Not really.

If I wanted to avoid that problem, I'd put the extension in "shared_preload_libraries",
so that _PG_init() is executed when the server starts.

Yours,
Laurenz Albe

view thread (3+ messages)

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