Re: [PATCH] DefaultACLs - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: [PATCH] DefaultACLs
Date
Msg-id a301bfd90907170155l19552d6dj33cddf18553ef232@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] DefaultACLs  (Petr Jelinek <pjmodos@pjmodos.net>)
Responses Re: [PATCH] DefaultACLs
List pgsql-hackers
Hi,

>>
>
> No, DefaultACLs applies to objects created in the future while GRANT ON ALL
> affects existing objects.

I see.

> DefaultACLs is more important functionality so it should probably take
> precedence in review process.
>
> There is however one thing that needs some attention. Both patches add
> distinction between VIEW and TABLE objects for acls into parser and they
> both do it differently. GRANT ON ALL works by adding ACL_OBJECT_VIEW and
> tracks that object type in code (that was my original method in both
> patches) while DefaultACLs uses method suggested by Stephen Frost which is
> creating new enum with relation, view, function and sequence members (those
> are object types for which both DefaultACLs and GRANT ON ALL are
> applicable). The second method has advantage of minimal changes to existing
> code.

I briefly looked at the DefaultACLs patch. Can you not re-use the
GrantStmt structure for the defaults purpose too? You might have to
introduce an "is_default" boolean similar to the "is_schema" boolean
that  you have added in the "GRANT ON ALL" patch. If you think you can
re-use the GrantStmt structure, then we might as well stick with the
existing object type code and not add the enums in the DefaultACLs
patch too..

Regards,
Nikhils
-- 
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Review: support for multiplexing SIGUSR1
Next
From: Fujii Masao
Date:
Subject: Re: Synch Rep for CommitFest 2009-07