On 03/11/2014 09:57 AM, Tom Lane wrote:
Magnus Hagander <mag...@hagander.net> writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the fact that I have *never* come across it on any system I've
come across since, well, forever. Except once I think, many years ago, when
someone had enabled it by mistake and needed my help to remove it...
A slightly more scientific basis for that would be to ask on
pgsql-general.
Or if someone wants to fix it properly of course :)
Yeah, that's what we've been hoping for for 12 years. I stopped holding
my breath awhile ago.
Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
has been. I'm just expecting lots of push-back if we try. And it's kind
of hard to resist push-back when you don't have a substitute to offer.
Or we try to make it work. I don't think the idea is inherently bad, and
I know there are people (like ISPs) who would like to have it work
properly. Maybe in these days when most people are on dedicated VMs this
matters less, but I don't think shared database servers are totally dead
yet.
The docs say:
db_user_namespace causes the client's and server's user name
representation to differ. Authentication checks are always done with
the server's user name so authentication methods must be configured
for the server's user name, not the client's. Because md5 uses the
user name as salt on both the client and server, md5 cannot be used
with db_user_namespace.
Is that the only major issue? Why not have the server strip out the @db
part if this is on? If we made this an initdb-time setting rather than a
GUC then we'd remove the problems caused by turning this on and off. I'm
not sure what other problems that might cause, but it doesn't seem
totally intractable at first glance.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
