Awhile back I complained that while all the core geometric datatypes
use operator @ to mean "contained in" and operator ~ to mean "contains",
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
There was some followup discussion generally agreeing that we ought to
get these things in sync, but then Andrew@supernews threw a monkey
wrench into the proceedings by suggesting we change to different names
entirely:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01263.php
That is not necessarily a bad idea, but I didn't want to get drawn
into a debate about exactly what alternative names to adopt, so I
dropped the problem for the time being.
I now find that the GIN patch has propagated the contrib meanings
of these operators into the core:
http://archives.postgresql.org/pgsql-general/2006-09/msg00087.php
and at this point I'm going to put my foot down and insist that
we do *something*. I won't hold still for fundamentally backward
meanings of the same operator name within the core datatypes.
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are out of sync (Michael Fuhr points out that
contrib/intarrayis out of step too ... are there others?).
3. Leave the existing op names as-is in core and contrib, but consider them deprecated and add new ops with
consistently-chosennames. (The new ops introduced by GIN should only exist with the new names.)
#1 isn't doing anything towards solving the underlying problem.
#2 has got obvious backwards-compatibility issues for contrib users.
#3 may or may not be technically feasible (I'm not sure if we can
support multiple operators occupying the same slot in an opclass),
besides which choosing the names to use could degenerate to a flamewar.
Thoughts, votes, better ideas? The only option I'm *not* open to is
leaving HEAD as it stands.
regards, tom lane
