Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(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-05-02 13:38:55
Message-ID: 200405021338.i42Dctk15110@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
OK, patch reverted at request of Tom and Peter.  Please propose a more
generalitzed soluion.  Thanks.

---------------------------------------------------------------------------

Fabien COELHO wrote:
> 
> 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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2004-05-02 13:52:43
Subject: Re: SET WITHOUT CLUSTER patch
Previous:From: Andrew DunstanDate: 2004-05-02 13:36:32
Subject: Re: Fixed directory locations in installs

pgsql-committers by date

Next:From: Bruce MomjianDate: 2004-05-02 13:39:51
Subject: pgsql-server/src/include/catalog catversion.h
Previous:From: Bruce MomjianDate: 2004-05-02 13:38:28
Subject: pgsql-server/src backend/utils/adt/acl.c inclu ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group