On Wed, 31 Jul 2002, 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. (Actually, createuser script would fail because
> it connects only to template1. You would have to use psql and CREATE
> USER. Probably other things would fail too.)
Sounds like a good solution that eliminates Tom's idea of going with
'local to database' pg_shadow files ... I like it ...
> As for 7.3, maybe we can get that done in time of everyone likes it.
> If we can't, what do we do? Do we re-add the secondary password file
> stuff that most people don't like? My big question is how many other
> PostgreSQL users figured out they could use the secondary password file
> for username/db restrictions? I never thought of it myself. Maybe I
> should ask on general.
How many ppl that aren't subscribed to any of the lists are using this and
are going to get burned royal when they upgrade to v7.3 without
understanding it is gone?
> Marc, you do have a workaround for 7.3 using your IP's, right, or is
> there a problem with the password having to be the same for different
> hosts with the same username? If Marc is the only one, and he has a
> workaround, we may just go ahead and leave it for 7.4.
No, unfortunately, I have at least one specific application that needs
this :( IPs help reduce the impact of losing this, but with the growing
difficultly and cost of acquiring new IPs, the IPs don't help much either
:(