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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers