tomas@tuxteam.de writes:
> "Operator class group", unwieldy as it is, conveys the meaning that we
> are talking about _sets of operator classes_. The nicer terms I have
> seen all lose a bit of that ring to me.
The thing is that in the proposal as it currently stands, we're *not*
talking about sets of operator classes, because a group can contain
"free standing" operators as well. So the apparent technical accuracy
is really a bit misleading.
As I'm currently thinking about it, a group is a collection of
compatible operators, and the fact that it has some of those operators
in common with an opclass is almost incidental --- not from the index
AM's point of view maybe, but there will be large chunks of the system
that work with groups without ever thinking about opclasses.
Another thing that struck me this morning is that we make very heavy
use of the shorthand "opclass" in both the code and the docs. If we
call these things "operator groups" then we can use the parallel
construction "opgroup", which seems to read OK to me. But if they're
"operator class groups" we'll be stuck with something like
"opclassgroup" ... ugh.
regards, tom lane