From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: custom variable classes |
Date: | 2006-11-28 21:32:38 |
Message-ID: | 6612.1164749558@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-11-28 21:35:00 | Re: [COMMITTERS] pgsql: Fix some translator comments so that |
Previous Message | Andrew Dunstan | 2006-11-28 21:19:04 | Re: custom variable classes |