Re: custom variable classes
От | Tom Lane |
---|---|
Тема | Re: custom variable classes |
Дата | |
Msg-id | 28212.1164739591@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | custom variable classes (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: custom variable classes
Re: custom variable classes |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: