Re: Open 7.3 items

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Open 7.3 items
Дата
Msg-id 1028285772.14586.24.camel@taru.tm.ee
обсуждение исходный текст
Ответ на Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Karel Zak
Дата:
Сообщение: Re: getpid() function
Следующее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: Rules and Views