Re: custom variable classes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: custom variable classes
Date
Msg-id 6612.1164749558@sss.pgh.pa.us
Whole thread Raw
In response to Re: custom variable classes  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: custom variable classes  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> How about we just compare that to the current definition source of the
>> value, and if we see it's been set improperly, revert the value to
>> default?

> Sounds interesting - can you expand on this a bit?

define_custom_variable() shouldn't just blindly accept the current
setting, but should check to see where it came from, and dig down to the
reset setting if the current source wouldn't have been allowed to set
the variable according to the now-known context.  (As noted in the
comments, that routine is a crock anyway, since it only tries to
transfer the "current" setting, not any stacked or reset settings.)

> Where is the wired-in default for a custom GUC var? This whole thing 
> needs some documentation, ISTM.

It appears to be whatever is the current content of the physical
variable at the instant DefineCustomFooVariable is called.  The whole
thing looks pretty poorly thought through, as well as undocumented...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: custom variable classes
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Fix some translator comments so that