Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced

Narek Galstyan <narekg(at)berkeley(dot)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