On Sun, Oct 16, 2016 at 4:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jim Nasby <Jim.Nasby@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.
I'm *definitely* -1 on renaming any of these existing operators.
> 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.
Agreed.
> 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.
Yeah, I think the value of operators other than the basic arithmetic
and logical operations is very low. I mean, if it's not going to be
familiar to people based on their general knowledge of mathematics
and/or other programming languages, it's actually easier to find a
function than it is to find an operator. If I want a function that
does something to do with counting, I can type:
\df *count*
If I want an operator that does something similar, I'm out of luck:
\do *count* looks for operators that contain count in the operator
name, not the description. Yeah, that could be changed, but
bits_count() is a lot easier to remember than # or whatever.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
