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

Re: custom variable classes

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: custom variable classes
Date: 2006-11-29 15:09:12
Message-ID: 456DA298.5070603@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 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.)
>
>   


I think the first hurdle we have to get over is that supplying any 
context other than PGC_USERSET seems to fail, even if the var is 
actually set in the corrresponding place (e.g. postgresql.conf) - I 
recall I had this trouble with plperl.use_strict, and Andrew(at)Supernews 
tells me he has had similar issues.


cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-11-29 15:38:44
Subject: Re: Regarding PQputline and PQendcopy
Previous:From: Andrew DunstanDate: 2006-11-29 14:16:48
Subject: Re: Regarding PQputline and PQendcopy

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