Re: custom variable classes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: custom variable classes
Date: 2006-11-28 18:46:31
Message-ID: 28212.1164739591@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Browne 2006-11-28 18:48:11 Re: FAQs and Port Status
Previous Message Matteo Beccati 2006-11-28 18:27:24 Re: [HACKERS] FAQs and Port Status