From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Vince Vielhaber <vev(at)michvhf(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Open 7.3 items |
Date: | 2002-08-14 23:58:31 |
Message-ID: | 17773.1029369511@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I don't know where else to go with the patch at this point. I think
> increasing the number of 'global' users is polluting the namespace too
> much,
Why? If the installation needs N global users, then it needs N global
users; who are you to make that value judgment for them?
In practice I think an installation that's using this feature is going
to have a pretty small number of global users, and so the issue of
collisions with local usernames isn't really as big as it's been painted
in this thread. We could ignore that issue (except for documenting it)
and have a perfectly serviceable feature.
But I don't think it's a wise idea to design the thing in a way that
makes it impossible to have more than one global user.
If you don't like including all the pg_shadow entries in the flat file
(though I really don't see any problem with that), could we replace
PG_INSTALL with a pg_global_users config file that lists the global user
names? I think it would be good enough to let this be hand-maintained,
with initdb initializing it to contain the install user's name.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2002-08-14 23:59:33 | Re: Open 7.3 items |
Previous Message | Bruce Momjian | 2002-08-14 23:44:25 | Re: Open 7.3 items |