Re: Advice regarding configuration parameters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Hallgren <thhal(at)mailblocks(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Advice regarding configuration parameters
Date: 2004-02-06 17:29:33
Message-ID: 1449.1076088573@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2004-02-06 17:33:20 Re: [GENERAL] dblink - custom datatypes don't work
Previous Message Joe Conway 2004-02-06 17:07:43 Re: Advice regarding configuration parameters