ADQL v0.7.3

[Martin Hill]

It makes sense to be explicit about cases where order matters.

However (or have I lost my logic marbles?) the order is not important in 
a set of AND expressions, or a set of OR expressions.  By restricting 
the number of arguments in AND or OR statements to 2, we:

1) Make long Unions and Intersections far more verbose than they need to 
be (and you all know how much I hate that - and will astronomer users 
like it?)

2) Prevent the interpreter at the backend from optimising unions simply. 
  If the interpreter at the backend has to realise that ((a AND b) AND 
c) is equivelent to (a AND (b AND c)) is equivelent to (a AND b AND c) 
then let's say so in the language.  That will make it easier to write 
specialised interpreters for non-SQL databases.

Cheers,

Martin

Clive Page wrote:

> On Tue, 2 Mar 2004, Tony Linde wrote:
> 
> 
>>The statement
>>  a / b / c / d
>>is perfectly valid. It is up to the interpreter what is done with it.
> 
> 
> I had been keeping my head down, but this makes me want to say that it is
> vital that we get this right, or at least make it clear what the right
> interpretation is.
> 
> Recently I got caught when translating some code from Fortran90 code into
> pl/pgSQL for Postgres (to implement HEALPix indexing).  The expression
> "a / b / c"
> has a clear Fortran interpretation of
> "(a/b)/c"
> but I discovered by getting wrong answers that in Postgres's version of
> SQL at least it is interpreted as
> "a/(b/c)".
> I found it _very_ hard to discover this in the Postgres manual, and in
> the SQL92 standard.
> 
>