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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers