Re: Open 7.3 items - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Open 7.3 items
Date
Msg-id 1028285772.14586.24.camel@taru.tm.ee
Whole thread Raw
In response to Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Thu, 2002-08-01 at 23:20, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > > I 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.

This should be settable using a GUC variable (in postgresql.conf as it
makes no sense once you are connected).

> > > > 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.
> > 
> > Stupid qustion .. but why can't you just add a 'domain' column to
> > pg_passwd/pg_shadow so that its stored as two fields instead of one?
> > Which I believe is what Pter is/was suggesting ...
> 
> Right now, pg_pwd only dumps users with passwords, and as I remember, it
> is only accessed when the protocol needs to lookup a password.  It
> wasn't designed for anything more advanced.  If you want separate
> columns, you have to dump out everyone, and modify CREATE USER,
> createuser, ALTER USER, ... to handle those new domain names, and you
> have to make this API visible to everyone even if they are not using
> domains.  That's where things really get ugly.

Actually _not_ modifying the commands (and thus leaving the
pg_shadow.usedomain column empty) will give us exactly the old
behaviour. For advanced uses it should be an acceptable interim solution
to have the superuser update the pg_shadow manually.

But if noone has time to work on it more than just mangling usernames at
connect time, that should also be ok for 7.3. We just have to document
it and warn of a new change to real domain  users in 7.4 (or later).

--------------
Hannu



pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: getpid() function
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Rules and Views