public inbox for [email protected]
help / color / mirror / Atom feedReserving GUC prefixes from a non-preloaded DB extension is not always enforced
3+ messages / 3 participants
[nested] [flat]
* Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
@ 2024-06-13 19:26 Narek Galstyan <[email protected]>
2024-06-13 19:39 ` Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced Tom Lane <[email protected]>
2024-06-14 07:44 ` Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced Laurenz Albe <[email protected]>
0 siblings, 2 replies; 3+ messages in thread
From: Narek Galstyan @ 2024-06-13 19:26 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
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
--
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
2024-06-13 19:26 Reserving GUC prefixes from a non-preloaded DB extension is not always enforced Narek Galstyan <[email protected]>
@ 2024-06-13 19:39 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: Tom Lane @ 2024-06-13 19:39 UTC (permalink / raw)
To: Narek Galstyan <[email protected]>; +Cc: [email protected]; [email protected]
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
2024-06-13 19:26 Reserving GUC prefixes from a non-preloaded DB extension is not always enforced Narek Galstyan <[email protected]>
@ 2024-06-14 07:44 ` Laurenz Albe <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: Laurenz Albe @ 2024-06-14 07:44 UTC (permalink / raw)
To: Narek Galstyan <[email protected]>; [email protected]; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-06-14 07:44 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-13 19:26 Reserving GUC prefixes from a non-preloaded DB extension is not always enforced Narek Galstyan <[email protected]>
2024-06-13 19:39 ` Tom Lane <[email protected]>
2024-06-14 07:44 ` Laurenz Albe <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox