DB-local usernames
pgman wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
OK, I have attached a patch for testing. Sample output is:
$ sql -U guest test
psql: FATAL: user "test.guest" does not exist
$ createuser test.guestI will object to any scheme that makes any characters in the user name
magic. Two reasons: First, do it right, make a separate column.
Second, several tools use URI syntax to specify data sources. This will
break any feature that relies on being able to put special characters into
the user name.The right solution to having database-local user names is putting extra
information into pg_shadow regarding which database this user applies to.
It could be an array or some separate "authentication domain" thing.OK, if you object, you can say goodbye to this feature for 7.3. I can
supply the patch to Marc and anyone else who wants it but I am not
inclined nor convinced we need that level of work for this feature.So we end up with nothing.
I have given this some thought. Peter's objection was that he objects
to any change that "makes any characters in the user name magic".
I don't think my patch does that. If you don't enable the feature,
everything works just the same. If you turn it on, it unconditionally
prefixes the username with the database name and a period. You can
still have periods in the username. The code doesn't check for any
periods in the username passed to the backend.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Import Notes
Reply to msg id not found:
On Tue, 2002-08-06 at 08:43, Bruce Momjian wrote:
I have given this some thought. Peter's objection was that he objects
to any change that "makes any characters in the user name magic".I don't think my patch does that. If you don't enable the feature,
everything works just the same. If you turn it on, it unconditionally
prefixes the username with the database name and a period. You can
still have periods in the username. The code doesn't check for any
periods in the username passed to the backend.
what about :
[hannu@taru hannu]$ createdb this.is.legal.database.name
CREATE DATABASE
[hannu@taru hannu]$ psql this.is.legal.database.name
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
this.is.legal.database.name=#
---------------
Hannu
Oh, well backend sees the user as this.is.legal.database.name.user.
The only case I can see a problem would be you have my.db.name and
db.user as legal _and_ my.db and name.db.user as legal. That is clearly
a problem becuase they appear the same when logging in.
Can anyone think of a way to get this to work _without_ pushing the
complexity into the user administration commands? That is what is
preventing me from creating a separate field in pg_shadow.
---------------------------------------------------------------------------
Hannu Krosing wrote:
On Tue, 2002-08-06 at 08:43, Bruce Momjian wrote:
I have given this some thought. Peter's objection was that he objects
to any change that "makes any characters in the user name magic".I don't think my patch does that. If you don't enable the feature,
everything works just the same. If you turn it on, it unconditionally
prefixes the username with the database name and a period. You can
still have periods in the username. The code doesn't check for any
periods in the username passed to the backend.what about :
[hannu@taru hannu]$ createdb this.is.legal.database.name
CREATE DATABASE
[hannu@taru hannu]$ psql this.is.legal.database.name
Welcome to psql, the PostgreSQL interactive terminal.Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quitthis.is.legal.database.name=#
---------------
Hannu---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Can anyone think of a way to get this to work _without_ pushing the
complexity into the user administration commands? That is what is
preventing me from creating a separate field in pg_shadow.
I'd definitely prefer not to do that. We have not really thought
through the implications. The original idea here was a quick-and-dirty,
easily ignored, optional feature to support per-database user name
assignment. Turning it into something more will require a lot of design
work that we haven't done, and IMHO don't have time for before 7.3.
BTW, I still prefer "user@dbname" to "dbname.user".
regards, tom lane