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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
