Re: @ versus ~, redux

Tom Lane wrote:
> 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/intarray is 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-chosen names.
>    (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.
>
>     
>
>   

How about?:

4. do 1+3, i.e. flip the GIN operators to keep core consistency, but 
deprecate the operators for both contrib and core. Something more 
visually like set ops would be ideal.

cheers

andrew