On Tue, Feb 22, 2011 at 9:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, unfortunately, there's an awful lot of information that can only
>> be obtained in a reasonable way by introspection of the system
>> catalogs. If you want to know whether user A can select from table B,
>> there's really no sensible way of obtaining that without parsing the
>> aclitem entries in some fashion, and unfortunately that's just the tip
>> of the iceberg.
>
> Um, that question is precisely why we invented the has_foo_privilege
> class of functions.
OK, fair point.
> I would *much* rather see users applying those
> functions than looking at ACLs directly --- and if there's some
> reasonable use-case that those don't cover, let's talk about that.
Well, the obvious applications are "I'd like to know who has
permissions on this item" and "I'd like to know what this user has
permissions to do".
>> Now, if you were to propose adding a well-designed set of DCL commands
>> to expose this kind of information to clients in a more structured
>> way, I would be the first to applaud. LIST TABLES? SHOW GRANTS TO?
>> Sign me up! (I got a request for the latter just today.) But until
>> then, if you need this information, you don't have much choice but to
>> pull it out of the system catalogs; and if JDBC would rather use
>> binary format to talk to the server, I don't particularly see any
>> reason to say "no". If we prefer to expose the text format rather
>> than anything else, that's OK with me, but I do think it would make
>> sense to expose something.
>
> Well, to go back to the binary-format issue, if we're going to insist
> that all standard types have binary I/O support then we should actually
> do that, not accept piecemeal patches that move us incrementally in that
> direction without establishing a policy. To my mind, "establishing a
> policy" would include adding a type_sanity regression test query that
> shows there are no missing binary I/O functions.
That's hard to disagree with. +1 for accepting a patch that fixes all
the remaining cases, but not anything less than that.
> smgr: let's just get rid of that useless vestigial type.
Heck yeah. Even if we someday want to go back to supporting more than
one smgr, the chances that we're going to want to do it this way are
just about zero.
This part probably merits its own commit, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
