Re: Precedence of '|' operator (was Re: [patch, rfc] binary operators on integers)

On Thu, Oct 12, 2000 at 04:18:05PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane writes:
> >> Even though I think '|' is clearly given a bogus precedence, I doubt
> >> it's a good idea to change it.
>
> > The only builtin '|' operator, besides the not-there-yet bitor, is some
> > arcane prefix operator for the "tinterval" type, which returns the start
> > of the interval. This is all long dead so that would perhaps give us a
> > chance to change this before we add "or" operators. That might weigh more
> > than the possibility of a few users having highly specialized '|'
> > operators that rely on this precedence.
>
> Well, that's a good point --- it isn't going to get any less painful to
> fix it later. Do we want to just remove the special treatment of '|'
> and let it become one with the undifferentiated mass of Op, or do we
> want to try to set up reasonable precedence for all the bitwise
> operators (and if so, what should that be)? The second choice has a
> greater chance of breaking existing apps because it's changing more
> operators ...
>
For bitops it would be nice if '~' had a precedence equal to other
builtin unary operators, '&' had higher precedence than '#' and '|'.
(C has also XOR higher that OR).

About breaking existing apps - all those operators [~|#&] are
not actually in use (well, in PostgreSQL mainstream) Only
bitstring in 7.1 will start using them and I guess it has hopefully
same precedence needs :) But yes, some outside add-on may use
them or maybe when in future those ops will be used for something
else then it will be messy...

Well, it is not for me to decide, but a Nice Thing would be:
(Looking at 'Lexical precedence' in docs)

[- unary minus] '~' unary BITNOT

...

[+ - add sub]
& BITAND
[ IS ]

...

[(all other) ] '#', '|'

Also note that bitstring uses '^' for xor so it has a little
weird rules and is inconsistent with this.

--
marko