Andrew Dunstan <andrew@dunslane.net> writes:
> One thing I want to look at for 8.3 is improving custom variable
> classes. Right now these are all user settable, which makes them quite
> inappropriate for security related settings (such as which perl modules
> to load for use by trusted plperl). I'm wondering if we should perhaps
> allow something like:
> custom_variable_classes = 'foo'
> foo:<security_level>.bar = 'blurfl'
This seems really ugly --- for one thing, what if the DBA gets it wrong?
The value won't mean anything until the code that uses it gets loaded,
at which time the correct GucContext for the variable will be supplied.
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?
It might also be a good idea to disallow ALTER USER/DATABASE SET for a
custom variable that's a placeholder, since we don't at that time know
if the value should be SUSET or not; and there seems no pressing need to
allow these ALTERs to be done without having loaded the defining module.
[ thinks for a bit... ] With that provision in place, I think it would
be safe to revert to the "reset" value instead of the wired-in default,
which would be marginally nicer.
regards, tom lane