Re: Controlling changes in plpgsql variable resolution
От | Josh Berkus |
---|---|
Тема | Re: Controlling changes in plpgsql variable resolution |
Дата | |
Msg-id | 4ADF4BF9.2080601@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Controlling changes in plpgsql variable resolution (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Controlling changes in plpgsql variable resolution
|
Список | pgsql-hackers |
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. Then we'd have the simple factor of setting it in postgresql.conf or setting it in the function definitions via WITH. --Josh Berkus
В списке pgsql-hackers по дате отправления: