Martijn van Oosterhout <kleptog@svana.org> writes:
> I think we're on the same page. I thought of another motivation also:
> protections/permissions. We don't currently allow people to mess with
> definitions needed by system catalogs, so you don't want to allow users
> to mess with the btree(int4) class, but you want to allow them to
> modify the group as a whole to add new things and remove things they've
> added.
Yeah. We're a long way from letting non-superusers manipulate opclass
definitions, but it'd be good if the structure were not one that would
forbid using permissions in future.
I'm still not real happy with the phrase "operator class group"; it
seems unwieldy, and it's not even technically accurate in this design,
since the structure can contain operators directly not only operator
classes. What do people think about calling it just an "operator
group"? That's sort of reasonable since really what we're doing is
saying that all these operators are compatible. (A lot of the things
the planner wants to do with this info have nothing to do with indexes
anyway.)
The main objection I can think of is that a novice seeing the terms
"operator class" and "operator group" isn't going to have any context
to know which is which, but I'm not sure that we can devise any terms
that would help much.
regards, tom lane