Hi,
>> 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..
>
> Petr and I discussed this. Part of the problem is that the regular
> grant enums don't distinguish between TABLE and VIEW because they don't
> need to. We need to with DefaultACL because users see those as distinct
> types of objects even though we track them in the same catalog.
> Splitting up RELATION into TABLE and VIEW in the grant enum would
> increase the changes quite a bit in otherwise unrelated paths.
> Additionally, not all of the grantable types are applicable for
> DefaultACL since DefaultACLs are associated with objects in schemas
> (eg: database permissions, schema permissions, etc).
>
Ok.
> We can certainly do it either way, but I don't see much downside to
> having a new enum and a number of downsides with modifying the existing
> grant enums.
>
Sure, I understand. But if we want to go the DefaultACLs way, then we
need to change the "GRANT ON ALL" patch a bit too for the sake of
uniformity - don't we? There is indeed benefit in managing ACLs for
existing objects, so that patch has some value too.
Regards,
Nikhils
--
http://www.enterprisedb.com