On Fri, Sep 29, 2006 at 11:55:18PM -0400, Bruce Momjian wrote:
> 
> Added to TODO:
> 
>       * Allow more complex user/database default GUC settings
>       
>         Currently, ALTER USER and ALTER DATABASE support per-user and
>         per-database defaults.  Consider adding per-user-and-database
>         defaults so things like search_path can be defaulted for a
>         specific user connecting to a specific database.

Is anybody claiming this TODO?  Is the design fleshed out enough for
someone to go forward with it?

Cheers,
D

> 
> ---------------------------------------------------------------------------
> 
> Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Fri, Sep 29, 2006 at 05:41:35PM -0400, Tom Lane wrote:
> > >> Yeah.  ISTM the correct generalization is "per-user per-database
> > >> default GUC settings", which has nothing to do with superuserness.
> > 
> > > This sounds like a TODO for 8.3.  What wrinkles might this involve?
> > 
> > Probably rethink the rolconfig/datconfig representation.  Maybe it's
> > time for a separate catalog for the settings.
> > 
> > > Offhand, I'm thinking that it would touch the inheritance stuff that
> > > roles have.
> > 
> > No, it wouldn't, because defaults only apply at the instant of
> > connection, so there's no inheritance or SET ROLE to worry about.
> > Whatever role you log in as is what you get.
> > 
> >                     regards, tom lane
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> 
> -- 
>   Bruce Momjian   [EMAIL PROTECTED]
>   EnterpriseDB    http://www.enterprisedb.com
> 
>   + If your life is a hard drive, Christ can be your backup. +

-- 
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to