Re: Controlling changes in plpgsql variable resolution
От | Robert Haas |
---|---|
Тема | Re: Controlling changes in plpgsql variable resolution |
Дата | |
Msg-id | 603c8f070910211137r7ed3fbe8hf0375fc3d9e8e7a0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Controlling changes in plpgsql variable resolution (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Controlling changes in plpgsql variable resolution
Re: Controlling changes in plpgsql variable resolution |
Список | pgsql-hackers |
On Wed, Oct 21, 2009 at 1:59 PM, Josh Berkus <josh@agliodbs.com> wrote: > Tom, > >> 1. Invent a GUC that has the settings backwards-compatible, >> oracle-compatible, throw-error (exact spellings TBD). Factory default, >> at least for a few releases, will be throw-error. Make it SUSET so that >> unprivileged users can't break things by twiddling it; but it's still >> possible for the DBA to set it per-database or per-user. >> >> 2. Also invent a #option syntax that allows the GUC to be overridden >> per-function. (Since the main GUC is SUSET, we can't just use a >> per-function SET to override it. There are other ways we could do this >> but none seem less ugly than #option...) > > Hmmmm. I don't see any reason why this couldn't be set by any user at > runtime, really. From a security standpoint, it's less of a risk than > search_path, and we allow anyone to mess with that. That's like saying that it's less of a risk than a group of rabid tyrannosaurs in a kindergarten classroom. ...Robert
В списке pgsql-hackers по дате отправления: