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
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 |