Re: Open 7.3 items

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

In response to

Browse pgsql-hackers by date

  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)