From: Petr Jelinek <pjmodos@pjmodos.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: GRANT ON ALL IN schema
Date: Wed, 05 Aug 2009 20:35:54 +0200
Message-ID: <4A79D10A.8060003@pjmodos.net> (raw)
In-Reply-To: <21542.1249492707@sss.pgh.pa.us>
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>
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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pjmodos@pjmodos.net, tgl@sss.pgh.pa.us
Subject: Re: GRANT ON ALL IN schema
In-Reply-To: <4A79D10A.8060003@pjmodos.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox