Re: Open 7.3 items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Open 7.3 items
Date
Msg-id 7164.1028211423@sss.pgh.pa.us
Whole thread Raw
In response to Re: Open 7.3 items  (Hannu Krosing <hannu@tm.ee>)
Responses Re: Open 7.3 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Open 7.3 items  (Hannu Krosing <hannu@tm.ee>)
Re: Open 7.3 items  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> This name mangling should be done at connect time and kept out of
> database, where each users name should always be fully resolved
> (bob@accounting.acme.com). 

I really like Hannu's approach to this.  It seems to solve Marc's
problem with a very simple, easily understood, easily implemented
feature.  All we need is a postmaster configuration parameter that
(when TRUE) causes the postmaster to convert the passed username
into 'username@databasename' before looking it up in pg_shadow.

(Actually, what I'd prefer it do is try first for username, and
then username@databasename if plain username isn't found.)

With this approach, we have an underlying mechanism that supports
installation-wide usernames, same as before, but with the flip of
a switch you can configure the system to support per-database
usernames.  It's not fancy, maybe, but it will get the job done
with an appropriate amount of effort.

We've had several proposals in this thread for complicated extensions
to the user naming mechanism.  I think that's overdesigning the feature,
because we have *no* examples of real-world need for such things except
for Marc's situation.  Let's keep it simple until we see real use cases
that can drive the design of something fancy.

> This may require raising the length of NAME type to be backwards
> compatible.

Right, but we're planning to do that anyway.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Trim the Fat (Was: Re: Open 7.3 items )
Next
From: Stephan Szabo
Date:
Subject: Re: Rules and Views