Skip site navigation (1) Skip section navigation (2)

Re: Open 7.3 items

From: nconway(at)klamath(dot)dyndns(dot)org (Neil Conway)
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Open 7.3 items
Date: 2002-08-01 03:38:34
Message-ID: 20020801033834.GB1461@klamath.dyndns.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jul 31, 2002 at 05:05:35PM -0400, Bruce Momjian wrote:
> OK, I have thought about this.  First, a possible solution would be to
> have a GUC variable that prepends the dbname to all username
> specifications, so the username becomes dbname.username.  When you
> CREATE USER "test", it actually does CREATE USER "dbname.test".  Same
> with ALTER/DROP user and lookups in pg_hba.conf and authentication. 
> Basically it gives us a per-db user namespace.  Only the superuser has a
> non-db qualified name.

What about the following situation:

    - 3 databases: 'devel', 'staging', and 'production'

    - one user, 'httpd', which needs access to all 3 databases but
      doesn't own any of them

    - I create the 'httpd' user when I'm connected to, say, template1

    - I issue a command that changes the httpd user in some way (e.g.
    drops the user, alters the user, etc.) -- what happens?

Also, what happens if I enable the GUC var, create a bunch of different
users/databases, and then disable it again?

Cheers,

Neil

-- 
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-01 03:40:43
Subject: Re: Open 7.3 items
Previous:From: Bruce MomjianDate: 2002-08-01 03:31:14
Subject: Re: Open 7.3 items

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group