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

Поиск
Список
Период
Сортировка
От Narek Galstyan
Тема Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
Дата
Msg-id CANdDwNJ0ab56KuvRSGBL_ZAnTs=_=Hzu9kdO=e2DB-dwtTTU0w@mail.gmail.com
обсуждение исходный текст
Ответы Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
Re: Reserving GUC prefixes from a non-preloaded DB extension is not always enforced
Список pgsql-general
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
--

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Reset sequence to current maximum value of rows
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Reset sequence to current maximum value of rows