Narek Galstyan <narekg@xxxxxxxxxxxx> 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
