Oliver Elphick wrote:
> > I agree with what Tom said, and understand why he said it. And I thought you
> > did, too -- I have apparently misunderstood (again!) the issue.
> > In the local-enabled scheme, ISTM the majority of users will be local users.
> > The goal is transparent virtual databases -- at least that's what I consider
> > the goal. As far as the user is concerned, the other databases might as well
> > not even exist -- all they are doing is connecting to their database. Since
> > they have to give the database name as part of the connection, it just makes
> > sense that they should have the closest to default behavior.
> > In the case of a virtual hosting postmaster, global users would likely be
> > DBA's, although they might not be. These users are going to be the
> > exception, not the rule -- thus a character to tag their 'exceptional'
> > nature.
> > You may not even want your virtual host local users to realize that there is
> > another user by that name. Thus, the standard notation is the least
> > intrusive for the very users that need uninstrusive notation.
> Has this behaviour been carried through into GRANT and REVOKE? If the
> object is transparency for local users, it should be possible in
> database "test" to say "GRANT ... TO fred" and have "fred" understood as
No changes have been made anywhere except for the username passed by the
client. All reporting of user names and all administration go by their
full pg_shadow username, so global user dave@ is dave in pg_shadow, and
dave is dave(at)db1 in pg_shadow. One goal of this patch was a small
> If that is the case, then I will support the current position.
> It follows from the objective of transparency that, when reporting a
> user name, local users should be reported without the database suffix,
> i.e., "fred" not "fred(at)test". Global users should be reported with the
> trailing "@". This should cause no problem, because we have no
> cross-database communication; it should be impossible for "george(at)dummy"
> to have any connection with database "test".
Nope, none of this is done and I don't think there is a demand to do it.
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2002-08-27 21:12:31|
|Subject: Re: [BUGS] Bug #718: request for improvement of /? to show|
|Previous:||From: Larry Rosenman||Date: 2002-08-27 21:08:16|
|Subject: Re: Proposed GUC Variable|