I also vote +1 for #3. Not only are there too many users, but simply
switching the sense of these operators will mean that code will still run,
but give incorrect answers and while it would be nice to think that all
client code has decent regression testing, this ain't the case.
If we are going to fix things so that all packages use the same sense, we
should slowly deprecate the current notation, and outright drop it for 8.2
or 8.3. What is the concensus: do it this release or next?
I also like the '@<' and '@>' notation as this gives a clear visual cue.
Josh Reich
> Oleg Bartunov <oleg@sai.msu.su> writes:
>>>> 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.)
>
>> #3 looks good to me. Too many users.
>
> Not only that, but it'd be a serious problem for something like a SQL
> script to be cross-version-compatible if we reverse the meanings of the
> existing operators.
>
> AFAIK all the operators in question exist only in GIST opclasses, so one
> possible solution to the multiple-operators-per-slot problem is to
> extend the opclasses --- ie, teach the gist_consistent methods to
> support two different strategy numbers that do the same thing. Ugly
> and tedious, but it'd preserve backward compatibility.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
