From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Ron Snyder <snyder(at)roguewave(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Open 7.3 items |
Date: | 2002-08-08 05:42:15 |
Message-ID: | 210.1028785335@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> 2. modify pg_user to show it usename usedomain as two separate fields
> for eas of use (join pg_user and pg_shadow on usesysid if you need to
> see passwords)
This is already more mechanism than I wanted to buy into, and less
forethought than I think we need. For example, is it a good idea if
pg_user shows usernames that cannot be identified with those shown by
ACL lists? If not, how will you modify ACL I/O formats? What about
the has_table_privilege functions?
What I'm envisioning is an extremely limited facility that just maps
connection parameters into an internal username that is of the form
username(at)dbname or dbname.username. Trying to hide that internal
username for inside-the-database activities does not strike me as a
good plan.
This may prove to be just a stopgap measure that we'll replace down the
road (as indeed the secondary-passwords thing was just a stopgap, IMO).
Let's not add features that will create extra compatibility problems
if we abandon the whole approach later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2002-08-08 06:19:13 | Re: Why is MySQL more chosen over PostgreSQL? |
Previous Message | Tom Lane | 2002-08-08 05:21:43 | Re: stand-alone composite types patch (was [HACKERS] Proposal: stand-alone composite types) |