Re: TODO item: Allow more complex user/database default GUC settings - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: TODO item: Allow more complex user/database default GUC settings
Date
Msg-id 65937bea0909212031l88be1f3wfee4496d2ee892ed@mail.gmail.com
Whole thread Raw
In response to Re: TODO item: Allow more complex user/database default GUC settings  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: TODO item: Allow more complex user/database default GUC settings
List pgsql-hackers
On Tue, Sep 22, 2009 at 4:16 AM, Bernd Helmle <mailings@oopsware.de> wrote:


--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?

ON instead of second ALTER looks better, and IMHO DATABASE <dbname> should be optional too:

ALTER ROLE <rolename> [ON DATABASE <dbname>] SET <config> TO <value>;

Best regards,
--
Lets call it Postgres

EnterpriseDB      http://www.enterprisedb.com

gurjeet[.singh]@EnterpriseDB.com

singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
Twitter: singh_gurjeet
Skype: singh_gurjeet

Mail sent from my BlackLaptop device

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Hot Standby 0.2.1
Next
From: Tom Lane
Date:
Subject: Re: TODO item: Allow more complex user/database default GUC settings