Re: GRANT ON ALL IN schema

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Petr Jelinek <pjmodos(at)pjmodos(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GRANT ON ALL IN schema
Date: 2009-08-05 17:18:27
Message-ID: 21542.1249492707@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Petr Jelinek <pjmodos(at)pjmodos(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-08-05 17:41:30 Re: the case for machine-readable error fields
Previous Message Sam Mason 2009-08-05 17:13:11 Re: the case for machine-readable error fields