From: | Petr Jelinek <pjmodos(at)pjmodos(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GRANT ON ALL IN schema |
Date: | 2009-08-05 18:35:54 |
Message-ID: | 4A79D10A.8060003@pjmodos.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-08-05 18:46:00 | Re: the case for machine-readable error fields |
Previous Message | Tom Lane | 2009-08-05 18:29:15 | Re: the case for machine-readable error fields |