Thread: Aclitem "high level description"

Dear committers, dear hackers,

> Subject: Re: [COMMITTERS] pgsql-server/src backend/utils/adt/acl.c ...
> > Ergo, my recommendation is to revert this change altogether.  Fabien
> > should figure out the high-level description of what he wants to know

Please find attached as somehow requested a plpgsql implementation for a
"high-level description" (by that, I understand "relationnal", not
"functionnal") of acl in postgres.

The pg_{database,class,namespace,language,proc}_acl views are just
intermediate for the construction of the description from current acl
implementation. I'm not sure the implementation is right about the default
settings, but the spirit is there.

The actual descriptions are pg_{public,group,user}_acl, and pg_granted_acl
and pg_acl are examples of how to use these "high level descriptions".

You may notice that "high level" means two different things. High level
functions from the back-end point of view (has_privileves stuff), and high
level relationnal (something you can query). I need the second stuff.

Also, I must admit that I don't find it really motivating to have to
reimplement all this in C and to have it rejected for some reason such as
"we may change things in this area in some hypothetical future time", as
it was the motivation for rejecting 10 lines of code for 5 aclitem
accessor functions.

A general comment about pg_catalog is that it looks like it was designed
by a C programmer and cast later as an afterthought to a relationnal view.
It makes it quite uneasy to manipulate these tables for any other purpose
that the one that was foreseen by the designer from its internal point of
view, especially as it is not normalized and as opaque types are used.

Anyway, thanks in advance for your comments about this description, and
suggestions about the probability of acceptance it could have (if
implemented properly in C) in the backend, so as to replace quite infamous
aclitem accessors.

Have a nice day,

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

Fabien COELHO wrote:
> Please find attached as somehow requested a plpgsql implementation
> for a "high-level description" (by that, I understand "relationnal",
> not "functionnal") of acl in postgres.

That doesn't tell me anything.  The functionality of the ACL system is 
to answer questions like "does user X have privilege Y on object Z".  
It seems that this question can be answered using existing facilities.  
Additionally we have information schema views that list existing 
privileges, and those views are defined using existing facilities.  It 
appears that your tables mostly duplicate that.  Can you say in words 
what information you are missing?

Dear Peter,

> The functionality of the ACL system is to answer questions like "does
> user X have privilege Y on object Z".

ONE OF the functionality, and THE functionality from the backend point
of view.

As I'm developing slowly a "pg_advisor" schema to check for various
consistency issues. For instance, "does all foreign key checks have
relevant indexes", things like that. I'm also considering writing views to
check for inconsistencies in the granted rights.

> It seems that this question can be answered using existing facilities.

Sure. But this is a functional interface for answering *one* specific
question, what is fine from the backend standpoint. The functions
hide queries to the raw data.

I'm rather trying to find *all* possible answers to some questions, so
typically this would be done with one single large query. For instance,
"is there a granted right in the system where the grantor does not have
the relevant grant options right?". The has_* interface does not allow
to answer to this question, I need to go back to the raw data.

As I already said, querying an array of opaque type is difficult.

> Additionally we have information schema views that list existing
> privileges, and those views are defined using existing facilities.  It
> appears that your tables mostly duplicate that.

Well, that is indeed possible to a partial extent.

On one of the first discussion about the advisor stuff, it appeared that
it was more interesting to rely on pg_catalog than on information_schema,
so I'm looking only at pg_catalog at the time.

One argument was that specific informations are only available in
pg_catalog. For instance, I need to check for acl about groups, but group
is pg-specific and does not appear in information_schema.

I hope that my intent is clearer, have a nice day,

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