Re: pgsql-server/src backend/utils/adt/acl.c inclu ...

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Neil Conway wrote:
>> Shouldn't this patch include some documentation updates?

> I talked to the author about this.  Turns out none of our permission
> functions have docs.

Really?  What is Table 9.37 in
http://developer.postgresql.org/docs/postgres/functions-misc.html
Arguably these functions do not belong right there, but that's hardly a
reason to think that they do not need documentation.

Personally, though, I think that Peter's original objection was right
on.  We shouldn't be exporting these functions at all; it is right to
treat aclitem as an opaque type.  The problem with allowing computations
on aclitems to occur in client-side code is that we will be locking
ourselves into the present representation of access rights, which is
pretty durn foolish considering that we *know* we need to make changes
in that area pretty soon to move closer to SQL compliance (the whole
users/groups/roles business).  The correct approach is not to export
low-level access and put functionality in the client, but to put the
functionality on the server side where it's convenient to change it
at the same time we reimplement ACLs.

Ergo, my recommendation is to revert this change altogether.  Fabien
should figure out the high-level description of what he wants to know
(at a level similar to has_table_privilege() and its ilk) and propose
server-side functions to implement that.

            regards, tom lane