Jim Nasby <jim.na...@bluetreble.com> writes:
> Personally I think it was a mistake to use # for intersection. Range
> doesn't do that (using * instead), and AFAICT PostGIS doesn't either
> (preferring &). So I propose renaming those operators, as well as the
> XOR ones. I think ^^ is pretty logical for XOR. I'm not sure about
> intersect... * doesn't seem like a good idea, && is overlaps, maybe &*.
I'm pretty much -1 on renaming any of these existing operators. There's
no realistic hope of having only one interpretation for an operator name
across all the different data types --- the best we can hope for, I think,
is consistency within a datatype family. For example, the reason not to
use ^ for integer XOR is that it also means exponentiation for
float/numeric, which are in the same class of datatypes. And your
proposal of ^^ doesn't satisfy anyone's notion of least astonishment.
As for renaming intersection, renaming operators that have had those names
since Berkeley, and are perfectly consistent within their datatype family,
seems likely to create much more pain than it removes.
As for counting bits in a bitstring, why do we have to make that an
operator at all? Using a function would decrease the stress involved
in choosing a name, and it's hard to believe that the requirement is
so common that we need to shave a few keystrokes. But if you must have
an operator there's not that much wrong with using prefix # for it.
> Related to this I'd also like to add a boolean XOR operator as that's a
> relatively common request/question.
We have boolean XOR; it's spelled "<>".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
