Re: GRANT ON ALL IN schema - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GRANT ON ALL IN schema
Date
Msg-id 21542.1249492707@sss.pgh.pa.us
Whole thread Raw
In response to Re: GRANT ON ALL IN schema  (Petr Jelinek <pjmodos@pjmodos.net>)
Responses Re: GRANT ON ALL IN schema  (Petr Jelinek <pjmodos@pjmodos.net>)
Re: GRANT ON ALL IN schema  (Josh Berkus <josh@agliodbs.com>)
Re: GRANT ON ALL IN schema  (Petr Jelinek <pjmodos@pjmodos.net>)
List pgsql-hackers
Petr Jelinek <pjmodos@pjmodos.net> writes:
> One more typo fix in docs

I took a quick look at this version of the patch.  Other than the
already-mentioned question of whether we really want to create a
distinction between tables and views in GRANT, there's not that
much there to criticize.  I do have a feeling that the implementation
is a bit too narrowly focused on the "stuff IN SCHEMA foo" case;
if we were ever to add other filtering options it seems like we'd
have to rip all this code out and start over.  But I don't have any
immediate ideas on what it should look like instead.

You mentioned that you weren't having any luck making "SCHEMA" optional
in the syntax.  I'm inclined to think it should be required rather than
leave it out entirely.  Leaving it out seems like it risks foreclosing
future expansion --- are we sure there will never be another selection
option that we'd want to start with IN?

Putting the search functions (getNamespacesObjectsOids and
getRelationsInNamespace) into aclchk.c doesn't seem quite right.
I'd have been inclined to put them in namespace.c instead, I think.
On the other hand objectNamesToOids hasn't been abstracted at all,
so maybe this is fine as-is.

Other than that I don't have much to say.  I wonder though if this
approach isn't sort of a dead-end, and we should instead look at
making it easier to build sql or plpgsql functions for doing bulk
grants with arbitrary selection conditions.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Sam Mason
Date:
Subject: Re: the case for machine-readable error fields
Next
From: "Kevin Grittner"
Date:
Subject: Re: the case for machine-readable error fields