From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql-server/src backend/utils/adt/acl.c inclu ... |
Date: | 2004-04-29 06:58:46 |
Message-ID: | Pine.LNX.4.58.0404290840010.11801@sablons.cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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(at)cri(dot)ensmp(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2004-04-29 14:08:10 | pgsql-server/src/interfaces/ecpg ChangeLog pre ... |
Previous Message | Tom Lane | 2004-04-29 05:08:33 | Re: pgsql-server/src backend/utils/adt/acl.c inclu ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Galbavy | 2004-04-29 07:10:19 | Re: What can we learn from MySQL? |
Previous Message | Tom Lane | 2004-04-29 05:10:17 | Re: 7.5 features |