Re: Open 7.3 items
От | Bruce Momjian |
---|---|
Тема | Re: Open 7.3 items |
Дата | |
Msg-id | 200208010340.g713eht25971@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Open 7.3 items (nconway@klamath.dyndns.org (Neil Conway)) |
Ответы |
Re: Open 7.3 items
|
Список | pgsql-hackers |
Neil Conway wrote: > 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? I am going to require the admin to prepend the dbname. GUC controls whether authentication/username map from just the client-supplied username, or the client username prepended with the dbname. > > Also, what happens if I enable the GUC var, create a bunch of different > users/databases, and then disable it again? You swap back and forth between users with prepended dbnames and those withouth. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: