Re: Advice regarding configuration parameters
От | Tom Lane |
---|---|
Тема | Re: Advice regarding configuration parameters |
Дата | |
Msg-id | 1449.1076088573@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Advice regarding configuration parameters (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Advice regarding configuration parameters
|
Список | pgsql-hackers |
Joe Conway <mail@joeconway.com> writes: > I still think it is a good idea and that > the difficulties can be worked out. What do you think of the idea of suppressing the "unknown variable" error for some class of variable names? If we had agreement on doing that then I think the rest would be pretty simple. After a few moments' thought I like the following sketch: * When a GUC setting read from postgresql.conf (or any other GUC setting source) contains an unknown variable name that fits the special class, create a "placeholder" GUC variable and insert it into the GUC variable array. The placeholder will be a STRING-type variable and will have a flag set to mark it as a placeholder. This flag would prevent it from being shown by SHOW ALL, but in other respects it would act like any other variable. * Subsequent manipulations, such as overriding of the value from ALTER DATABASE or other sources, will work normally. Therefore at all times we will have the correct setting of the placeholder available as a string. (Actually there are several settings: current, reset, etc, but we'd know them all.) * When and if the PL (or other shared library) that uses the variable is loaded, it will execute an "add_guc_variable" call during its one-time initialization. This new function either adds a GUC variable (if no match in the present GUC array) or replaces a placeholder variable (if found). In event that a placeholder is replaced, we convert the string value(s) as needed and assign to the newly defined variable. This scheme could not handle add-on GUC variables with some of the odder flags, such as GUC_LIST_INPUT, since the correct flag values wouldn't be known when the input is first seen. And we'd have to think a little about how to handle variable values that are discovered to be erroneous when we try to assign them to the variable --- probably we can just drop them, but does that make the semantics weird at all? But I think it would solve 99% of the problem for only a small amount of work. regards, tom lane
В списке pgsql-hackers по дате отправления: