From: | "Richard Huxton" <dev(at)archonet(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Richard Huxton" <dev(at)archonet(dot)com>, "Sean Chittenden " <sean(at)chittenden(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Per database users/admins, |
Date: | 2004-03-26 21:43:28 |
Message-ID: | 49175.192.168.1.32.1080337408.squirrel@mainbox.archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Richard Huxton <dev(at)archonet(dot)com> writes:
>> Maybe it's me being slow, but are we not being over-complicated here?
>> What's
>> wrong with saying "database D1 looks up users in local table, D2 in the
>> global table". If you are connected to D1, then no-one can see the
>> global
>> userlist.
>
> Hmm. That would amount to saying that there are no global superusers
> for D1, which might be a bit of a problem --- if local DBA paints
> himself into a corner, you can't get him out. Backing up a cluster that
> has not got global superusers would be a PITA too.
So you write a script to add a local superuser when you create the
database. Or, we could do it in the createdb/CREATE DATABASE code - just
clone the "postgres" user. Last resort, I'm sure the files themselves
could be hacked if you had to. If people are running a shared environment,
it's fair to assume they know a little of what they're doing.
> Still, I think you are right that we gotta think outside the box if
> we're going to find a way to do this.
More a case of thinking under the box here.
From | Date | Subject | |
---|---|---|---|
Next Message | markw | 2004-03-26 22:00:01 | PostgreSQL block size vs. LVM2 stripe width |
Previous Message | Tom Lane | 2004-03-26 21:30:39 | GIST code doesn't build on strict 64-bit machines |