Re: TODO item: Allow more complex user/database default GUC settings
От | Bernd Helmle |
---|---|
Тема | Re: TODO item: Allow more complex user/database default GUC settings |
Дата | |
Msg-id | A4B6B958EC4E1CBEAF5AD22B@amenophis обсуждение исходный текст |
Ответ на | Re: TODO item: Allow more complex user/database default GUC settings (Bernd Helmle <mailings@oopsware.de>) |
Ответы |
Re: TODO item: Allow more complex user/database default GUC
settings
|
Список | pgsql-hackers |
--On 21. September 2009 13:42:21 +0200 Bernd Helmle <mailings@oopsware.de> wrote: > > > --On 20. September 2009 22:56:53 -0400 Robert Haas > <robertmhaas@gmail.com> wrote: > >> So is this ready to commit, or what? > > Not yet, see the comments Alvaro did upthread. Please note that i'm still > reviewing this one and i hope to post results tomorrow (there wasn't > plenty of free time over the weekend, i'm sorry). > Here some further comments on the current patch: - I'm not sure i like the name of the new system catalog pg_setting. Wie already have pg_settings, i think this can be confusing. Maybe we need a different name, e.g. pg_user_setting? This seems along the line with the other *user* system objects (e.g. pg_stat_user_tables), where only "user specific" objects are displayed. - I have thought a little bit about the changes in the system views. pg_roles and pg_shadow (as Alvaro already mentioned), need to be adjusted (joined to the new catalog), to display rolconfig/useconfig. However, it's unclear *how* to expose those information, for example, do we want to expose roleconfig specific for the current database or for all databases the role has a specific config for ? - The code mentions the lack of lock synchronization. Maybe i'm missing something obvious (its late here), but is there a reason this can't be done by obtaining a lock on pg_authid (not sure about the backend user initialization phase though) ? - Regarding the missing UI: i go with Alvaro's proposal: ALTER ROLE <rolename> [ALTER] DATABASE <dbname> SET <config> TO <value>; Maybe we can make the 2nd ALTER optional. Thoughts? -- Thanks Bernd
В списке pgsql-hackers по дате отправления: