Added to TODO: * Allow custom variable classes that can restrict who can set the values
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00911.php --------------------------------------------------------------------------- Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq