ADQL 2.1: boolean literals and expressions

[Dave Morris]

Hi Markus,

On 2018-03-05 14:11, Markus Demleitner wrote:

> 
> (b) We already have 1=INTERSECTS, 1=CONTAINS, 1=ivo_nocase_match, and
> more.  If we now create boolean functions, we'll have more explaining
> to do as to where these odd beasts come from.
> 

The reason for adding boolean types and literals in 2.1, was to lay the 
ground work so that in a future version we could get rid of 
1=INTERSECTS, 1=CONTAINS etc.

The discussion about this goes all the way back to 2014
https://volute.g-vo.org/svn/trunk/projects/dal/TAPNotes/TAPNotes-fmt.html#af-booleans

At some point we decided that we needed to do it in two stages, 
introducing the boolean type and literals in this version and then 
converting INTERSECTS and CONTAINS etc. into boolean functions in the 
next.

I believe that the reason for the delay was that at the time some 
implementations were relying on text substitution to convert ADQL to 
SQL, and they would not be able to support boolean functions. Since then 
all of the implementations now use some form of grammar parsing and this 
restriction no longer applies.

I would have thought that in the long term, your example

   SELECT
     * FROM table
   WHERE
     contains(pt1, circ2)
   OR
     col_ref

is exactly the kind of thing we would want to be able to support.

So I guess the question is do we want to be able to replace

   WHERE 1 = CONTAINS(...)

with the simpler and more understandable

   WHERE CONTAINS(...)

at the price of more complicated and/or unclear error messages if the 
users gets the query wrong.


Hope this helps,
Dave

--------
Dave Morris
Research Software Engineer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------