ADQL: Bitwise operators

[Markus Demleitner]

Hi Dave,

On Tue, Feb 20, 2018 at 03:07:35AM +0000, Dave Morris wrote:
> On 2018-02-14 15:09, Markus Demleitner wrote:
> > 
> > The right way to deal with this would to have term and bitwise on two
> > different levels.  Inspecting the C precendence table as well as
> > postgres' behaviour, bitwise operators ought to bind less strongly
> > than + and -.  This would mean that <bitwise_expression> has to go
> > from <numeric_value_expression> and is used whereever right now we
> > have <numeric_value_expression>.  And then <bitwise_expression> would
> > have <numeric_value_expression> as its first alternative.
> > 
> 
> What if we replace this :
> 
[...]
> 
> With this :
> 
>     +   <numeric_value_expression> ::=
>     +       <numeric_term_expression>
>     +     | <bitwise_not> <numeric_value_expression>
>     +     | <numeric_value_expression> <bitwise_and>
> <numeric_term_expression>
>     +     | <numeric_value_expression> <bitwise_or>
> <numeric_term_expression>
>     +     | <numeric_value_expression> <bitwise_xor>
> <numeric_term_expression>
> 
>     +   <numeric_term_expression> ::=
>     +       <term>
>     +     | <numeric_term_expression> <plus_sign> <term>
>     +     | <numeric_term_expression> <minus_sign> <term>
> 
> Basically, rather than making 'bitwise_expression' the top of the tree,
> moving the name 'numeric_value_expression' up one level, to include what was
> in 'bitwise_expression', and then create a new name
> 'numeric_term_expression' to represent what was in the original
> 'numeric_value_expression'.
> 
> Does that solve the problem without costing too much ?

Well, at least *I* will still have to touch fairly fundamental code,
if only because unit and UCD induction of a*b and a/b are quite a bit
different from that of a & b or a | b.

All this is doable (and I prefer being honest about the names of the
nonterminals reflect what they stand for, so if we go ahead with
logical expressions, let's go all the way) -- but again: What's wrong
with functions, and is that bit of wrong large enough to warrant all
that messing around with grammar?

Now, if someone feels strongly enough for the logical operators to
put them in code and unit tests, I'll grudingly do the second
implemenation and move on. But even then I'm convinced:
BITWISE_NOT(x), BITWISE_AND(a,b), BITWISE_OR(a,b), and perhaps
BITWISE_XOR(a,b) are just fine, and our users will be happy to use
them in the relatively few cases they actually need them.

          -- Markus