Re: Open 7.3 items

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(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 22:28:26
Message-ID: 200208142228.g7EMSQQ23627@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


OK, I have a new idea. Seems most don't like that 'postgres' is a
special user in this context.

How about if we just document that they have to create a
postgres(at)template1 user before flipping the switch. That way, there is
no special user, no PG_INSTALLER file, and no double-tests for user
names.

It doesn't give us a global user, but frankly, it seems that such a
system is never going to work reliably.

Trying to prevent namespace conflicts by checking for users without @
that may match will make @ a special character in the user namespace,
and people won't like that.

---------------------------------------------------------------------------

Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > So the former plain 'postgres' user could still be such to us, to client
> > programs, etc, but the backend would assume that that meant
> > postgres(at)template1 -- no namespace collision, and the special case is that
> > anyone(at)template1 has the behavior the unadorned plain user now has.
>
> The trouble with that scheme is that there is zero interoperability
> between the plain-vanilla mode (postgres is postgres in pg_shadow) and
> the @-mode (postgres is postgres(at)template1 in pg_shadow). Flip the
> configuration switch, in either direction, and you can't log in anymore.
> We'd almost have to make it a frozen-at-initdb setting so that initdb
> would know which form to put into pg_shadow for the superuser, and so
> that entry wouldn't break thereafter.
>
> The reason I like the "lowen" vs "lowen(at)somedb" pattern is that
> database-global users can log in the same way whether the feature is
> turned on or not; this eliminates the getting-started problem, as well
> as the likelihood of shooting yourself in the foot.
>
> It is true that if you have a global user lowen you'd want to avoid
> creating any local users lowen(at)somedb, and that the existing code
> wouldn't be able to enforce that. We could possibly add a few lines
> to CREATE USER to warn about this mistake. (It should be a warning not
> an error, since if you have no intention of ever using the @-feature
> then there's no reason to restrict your choice of usernames.)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-14 22:32:35 Re: encrypted passwords
Previous Message Bruce Momjian 2002-08-14 22:20:24 Re: pg_dump output portability