Re: TODO item: Allow more complex user/database default GUC settings

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TODO item: Allow more complex user/database default GUC settings
Date: 2009-09-22 03:31:14
Message-ID: 65937bea0909212031l88be1f3wfee4496d2ee892ed@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 22, 2009 at 4:16 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:

>
>
> --On 21. September 2009 13:42:21 +0200 Bernd Helmle <mailings(at)oopsware(dot)de>
> wrote:
>
>
>>
>> --On 20. September 2009 22:56:53 -0400 Robert Haas
>> <robertmhaas(at)gmail(dot)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[(dot)singh](at)EnterpriseDB(dot)com

singh(dot)gurjeet(at){ gmail | hotmail | indiatimes | yahoo }.com
Twitter: singh_gurjeet
Skype: singh_gurjeet

Mail sent from my BlackLaptop device

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-22 04:07:40 Re: TODO item: Allow more complex user/database default GUC settings
Previous Message Jeff Janes 2009-09-22 02:42:33 Re: Hot Standby 0.2.1