ADQL XMATCH

[Theresa Dower]

While the issue of distance() being overloaded in ADQL remains, I wanted to note that for our use of SQL Server at STScI, we do enough query rewriting already that a translation from [something like] distance(....) would be basically the same work as we already have to do with contains().

I echo Alex's concern about calling something simple 'xmatch' when it isn't, or effectively putting the burden of a better crossmatch implementation on service providers. Something like distance(...) would be more honest, though I have no suggestion for quite what to call it without overloading that function.

--Theresa

-----Original Message-----
From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of Walter Landry
Sent: Wednesday, February 10, 2016 9:46 AM
To: dal at ivoa.net
Subject: Re: ADQL XMATCH

Grégory Mantelet <gmantele at ari.uni-heidelberg.de> wrote:
>     However, this kind of expression is performed by a sequential scan in
>     the database. As far as I know, there is no way to index or optimize
>     such constraint in a database (but I may be wrong so correct me if
>     needed). On the contrary, "contains(point, circle)" can use an index
>     (using PgSphere+Postgres for instance). So, I agree, it is ugly, but
>     it is more efficient.
> 
>     Then, maybe it is also possible to use some trick like detecting
>     "distance(ra1,dec1,ra2,dec2) < something" inside the ADQL query and
>     translate it into the equivalent of "contains(point,circle)" in
>     SQL....but it is really a ugly trick and may not be so trivial to
>     implement.

In my parser (I can not speak for others), implementing this is just recognizing this pattern to be semantically the same as CONTAINS.  It would be about the same amount of work as changing the parser to recognize XMATCH.  So not very much at all.  I think this is the easiest, most intuitive way forward, particularly with point literals.

Cheers,
Walter Landry