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

From Stephen Frost
Subject Re: [PATCH] DefaultACLs
Date
Msg-id 20090717124941.GO20436@tamriel.snowman.net
Whole thread Raw
In response to Re: [PATCH] DefaultACLs  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
Responses Re: [PATCH] DefaultACLs  (Nikhil Sontakke <nikhil.sontakke@enterprisedb.com>)
List pgsql-hackers
Nikhil,

* Nikhil Sontakke (nikhil.sontakke@enterprisedb.com) wrote:
> 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).

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.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: ECPG support for struct in INTO list
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193