Skip site navigation (1) Skip section navigation (2)

Re: custom variable classes

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-11-28 21:35:00
Subject: Re: [COMMITTERS] pgsql: Fix some translator comments so that
Previous:From: Andrew DunstanDate: 2006-11-28 21:19:04
Subject: Re: custom variable classes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group