Re: custom variable classes

On 2006-11-29, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Tom Lane wrote:
>> 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.

This is pretty much what Tom is getting at, I think. Currently, the reason
why only PGC_USERSET works is that all placeholders are created as
PGC_USERSET, and no attempt is made to record whether the user that set the
value was a superuser or not. Thus, when the module that uses the variable
tries to define it properly, the newly-defined variable is assigned the
value from the placeholder using PGC_USERSET, which obviously fails if the
module tried to define some more restrictive type.

Another potential pitfall is that all the initialization code for backend
arguments (from the command line or the startup packet) relies on knowing
in advance whether options are PGC_SUSET or not - the PGC_SUSET options
are set after InitPostgres(), whereas all other options are set before.
(We presumably don't actually know until after InitPostgres whether or
not we are actually a superuser...)

This is particularly annoying for me because what I wanted was to have a
superuser-only option that could be set in the startup packet. (I got the
effect of a superuser-only option by preloading my module and putting a
check for superuserness in the variable's 'set' hook, but that doesn't
work at backend startup time.)

I also ran into an issue with a boolean config var causing errors like
"invalid value: 1" at definition time, but I've not tracked this down.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services