Re: [PATCH] DefaultACLs

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Cc: Petr Jelinek <pjmodos(at)pjmodos(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] DefaultACLs
Date: 2009-07-17 12:49:41
Message-ID: 20090717124941.GO20436@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nikhil,

* Nikhil Sontakke (nikhil(dot)sontakke(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2009-07-17 12:58:27 Re: navigation menu for documents
Previous Message Michael Meskes 2009-07-17 12:43:37 Re: ECPG support for struct in INTO list