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)
