Lamar Owen <lamar.owen@wgcr.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@template1 -- no namespace collision, and the special case is that
> anyone@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@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@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@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
