ADQL XMATCH

[Markus Demleitner]

Hi Mark,

On Thu, Apr 14, 2016 at 05:46:12PM +0100, Mark Taylor wrote:
> Which thought nudges me to think about the consequences of
> overloaded geometry functions for TAPRegExt.
> 
> TAPRegExt 1.0 sec 2.3 says this about declaring geometry functions:
> 
>     ivo://ivoa.net/std/TAPRegExt#features-adqlgeo
>        Each feature declares support for one of the geometry functions
>        defined by ADQL (support for these functions is in general optional
>        for ADQL implementations, though TAP imposes some constraints on
>        what combinations of support are permitted).
> 
>        The signature of these functions, where supported, is fixed
>        by ADQL; the content of the form element is just the name of
>        the function.
> 
>        Example:
> 
>        <feature>
>          <form>CONTAINS</form>
>        </feature>
> 
> but if we're talking about overloads, there is no uniquely fixed
> signature for these functions.  In other words, TAPRegExt as

Well, it is if we say "Either implement all variants of a function or
none".  You'd simply not be allowed to have:

> support for overloaded standard geometry functions - a TAP service
> can't declare that it supports DISTANCE(POINT,POINT) but not
> DISTANCE(REAL,REAL,REAL,REAL).  (note this doesn't apply to

Since it's usually not hard to morph in the ADQL engine between the
two forms, I think that would be not unreasonable to specify in ADQL.

Cheers,

         Markus