ADQL XMATCH

[Tom McGlynn (NASA/GSFC Code 660.1)]

I'd like to clarify where the desire to avoid overloading comes from.

If I understand it, the issue with not overloading the distance function 
is that function overloading is not possible in some databases.  We 
envisage that we can define some new functions, and then underlying 
database will basically run the query without any need for us to worry 
about the details of the query.

I do not believe this approach is viable for any significant 
implementation of ADQL.  ADQL allows enormously complex queries and most 
databsae systems, Postgres, MySQL, SQLServer, ... have lots of 
constructs that can present major security threats  to a web site.  From 
an operational perspective, I would suggest that any non-toy ADQL 
service must parse the input queries for security and other reasons.  
Given this requirement, handling overloading of a function name is 
simple.  In the specific case at hand I can see how many arguments my 
distance function has and transform the name appropriately if needed if 
the database doesn't allow overloading.  It would be a bit harder if we 
had to handle overloading with the same number of arguments and 
different types, but that's not the case here.

Conversely, if we were to adopt Walter's proposal, I believe  it 
requires a change to the supported SQL syntax so if is likely to break  
existing parsers.   I suspect that in practice it would cause much more 
work than handling an overload.

I don't find the issues of extensibility particularly compelling. Note 
that a three-dimensional distance function typically represents 
something with  units of distance, while our two-d functions are 
normally dimensionless angles.  They are really different beasts.


However Walter's syntax is nice and clean and if we are going to be 
asking astronomers to actually write ADQL in our interfaces we should  
look at it.  Since we have to parse the SQL anyway -- see above -- 
providing  an elegant syntax would be really nice.  And I think that add 
a general transformation of
    {a,b} -> point('ICRS', a, b)
is probably not too difficult.


In the end I think we should decide based upon what makes it easiest for 
astronomers to do their research, since I believe any technical 
impediment to overloading is a chimera.
Personally, I'd recommend we implement both a four argument distance 
function and Walter's new syntax.

     Regards,
     Tom

Arnold Rots wrote:
> Maybe not surprisingly, I favor Walter's proposal.
> It has the distinct advantage that it is extensible
> and does not paint us into a corner.
> For instance, at some point the need may arise
> for distances in Cartesian coordinates
> (3-D spatial distances).
>
>   - Arnold
>
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots Chandra X-ray Science Center
> Smithsonian Astrophysical Observatory tel:  +1 617 496 7701
> 60 Garden Street, MS 67   fax:  +1 617 495 7356
> Cambridge, MA 02138 arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>
> USA http://hea-www.harvard.edu/~arots/ 
> <http://hea-www.harvard.edu/%7Earots/>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Thu, Apr 7, 2016 at 4:43 AM, Markus Demleitner 
> <msdemlei at ari.uni-heidelberg.de 
> <mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
>
>     Hi Walter,
>
>     On Wed, Apr 06, 2016 at 11:14:17AM -0700, Walter Landry wrote:
>     > Marco Molinaro <molinaro at oats.inaf.it
>     <mailto:molinaro at oats.inaf.it>> wrote:
>     >
>     > Since no one commented on it before, I would like to repeat my
>     > proposal for a point literal.
>     >
>     >   {a,b} -> POINT('ICRS GEOCENTER',a,b)
>     >
>     > Then the distance function would be
>     >
>     >   DISTANCE({ra1,dec1},{ra2,dec2})
>     >
>     > This would keep the function type safe and obviate the need for
>     a new
>     > overload for DISTANCE.
>
>     I suppose everyone was more or less like me: Nice, but is it really
>     worth introducing new syntax?  And will this be trouble later, when
>     we (perhaps) may deal with array literals?  Not sure.  Ah, let
>     someone else worry about it.
>
>     So, I can't give you more than a heartfelt "undecided".
>
>
>     DISTANCE with four floating-point arguments, on the other hand, sits
>     nicely in my comfort zone of probably making the average astronomer
>     happy while being very cheap -- after all, we have other functions
>     that admit a variable number of arguments and change behaviour
>     depending on the arity used. I'll just mention random here.
>
>     Cheers,
>
>              Markus
>
>