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

Dear Tom,

> 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.

Sure. I was planing to add something anyway.

> 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.

I disagree strongly on this point.

As I stated previously, it should a general principle that all information
about internal configuration should be available from SQL, and better if
in a relationnal form. This is among the "10 rules" of what a relationnal
DB should do, as far as I can remember.

Otherwise, it means that you do not trust SQL and the relationnal DB
as a general tool. As a leading developper in a RDB system, I cannot
believe that;-)

> The problem with allowing computations on aclitems to occur in
> client-side code

I'm developping some "pg_advisor" stuff to check for many things in the
database. YOU decided that all that should not be on the server side.
Fine, I agree. Now if you want to keep things opaque in the server...

> is that we will be locking ourselves into the present representation of
> access rights, which is pretty durn foolish.

I perfectly agree with you on this point;-)

The "pg_hba.conf" code is pretty disappointing. I mean by that low
level, no real internal data structure

The aclitem stuff violates all rules I teach to my student about
sound design: it is a array (no NF1) the same field references keys
in different arrays, a null array means something implicitly, aso.

> 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.

Well, it would be no big stuff to adapt this.

> Ergo, my recommendation is to revert this change altogether.

You're the boss.

> 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.

Sure, I did that already.

I built a plpgsql functions to return appropriate relations that I can
query. However this plpgsql needs to access your "opaque" type. I can load
the functions, but they seem to me that they belong to the backend.

"has_*_privileges()" is NOT relationnal as it hides queries, so it does
not really suit queries that want to deal with all possible users/groups
and all possible objects. Moreover, I need access to the raw information
to check for its consistency, not the derived functionnal stuff.

--
Fabien Coelho - coelho@cri.ensmp.fr