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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-29 15:38:44 Re: Regarding PQputline and PQendcopy
Previous Message Andrew Dunstan 2006-11-29 14:16:48 Re: Regarding PQputline and PQendcopy