Message-ID: <4A79D10A.8060003@pjmodos.net>
Date: Wed, 05 Aug 2009 20:35:54 +0200
From: Petr Jelinek <pjmodos@pjmodos.net>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: GRANT ON ALL IN schema
References: <4A37BF63.50008@pjmodos.net> <4A37E122.8070303@pjmodos.net>
	<4A38A956.8080600@pjmodos.net> <4A4DE104.8090605@pjmodos.net>
	<a301bfd90907170254re7dd52es9fedb007376d8055@mail.gmail.com>
	<4A6059B4.5010004@pjmodos.net> <4A607997.3030305@pjmodos.net>
	<21542.1249492707@sss.pgh.pa.us>
In-Reply-To: <21542.1249492707@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> 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.
>   
It is, I was thinking about making that bool is_schema something more 
useful like int search_option with enum associated with it. But if I do 
that it would be better to have more then one filter implemented in 
initial commit - maybe I could add that OWNED BY I was talking about, or 
do you have better suggestions ?

> 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?
>   
Ok I'll make it mandatory.

> 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.
>   
I wanted to be consistent with existing code there (the 
objectNamesToOids you mentioned) and I also didn't want to export those 
functions needlessly.

> 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.
>   
The whole reason for me to implement this thing is that I see something 
like "How can I grant rights to all existing objects in database?" 
question asked on irc channel like once a week. Most of the time those 
people only want to use that particular feature once after 
importing/creating schema so making function you'll only use once is not 
the optimal way to do it. And more importantly they expect this to be 
possible using standard SQL.

-- 
Regards
Petr Jelinek (PJMODOS)