Re: Add read-only param to set_config(...) / SET that effects (atleast) customized runtime options
От | Chapman Flack |
---|---|
Тема | Re: Add read-only param to set_config(...) / SET that effects (atleast) customized runtime options |
Дата | |
Msg-id | 8fd0abe0-ec63-6180-e753-89a780fb78e3@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: Add read-only param to set_config(...) / SET that effects (atleast) customized runtime options (Chapman Flack <chap@anastigmatix.net>) |
Список | pgsql-hackers |
On 04/20/2018 04:18 PM, Chapman Flack wrote: > On 04/20/2018 04:03 PM, Andrew Gierth wrote: >> Assign hooks aren't allowed to throw errors under any circumstance >> because they're called during transaction abort, and throwing an error >> during abort is obviously not tolerable. > > Ah yes, now you remind me, that was why I had put my extension idea > on the table at the time. > > It seems as if, for any of these ideas (cookie-protection of GUCs > or just SET READONLY for GUCs), at least some small patch to core > will be prerequisite, to allow either a flag or a reset check hook > able to make RESET skip protected GUCs. I suppose an extension could protect a GUC of its own from reset without the cookie, despite the lack of a reset hook in core, by simply maintaining its own copy of the original reset value, and stuffing the protected value into the variable's reset_val for the duration, no? Wouldn't be usable to protect core GUCs, but could provide an API for other extensions to make their GUCs protectable, by passing the config_* struct pointer to a registration function. -Chap
В списке pgsql-hackers по дате отправления: