ADQL-2.1 internal draft

[Marco Molinaro]

Hi Walter, hi all,

2015-06-12 23:03 GMT+02:00 Walter Landry <wlandry at caltech.edu>:
> Marco Molinaro <molinaro at oats.inaf.it> wrote:
>> Letting apart that mine was an example, I haven't checked all DBMSes
>> This doc page refers to reading number and type of arguments.
>> Overload of UDFs is not supported in MySQL, don't ask me why.
>> It's true that maybe if you hack the engine you can do something,
>> don't now, never tried.
>
> It does not require hacking the engine.  You define a single UDF that
> takes a variable number of arguments.  Inside the UDF, you check the
> arity and do the appropriate thing.

ok, so probably here is my fault, but I'd consider this something different
than overloading a function.
Anyway, that's ok, you can use this way to do it in MySQL, but, I stress,
that was not exactly my point.

>> In any case, I think that the overloading proposed to solve the
>> empty string to be deprecated is not an easy solution. What you say
>> can be used server side when receiving a call to the service (but
>> this can also be declared by the VERSION parameter), but you need
>> then a workaround client side, that has to find a way to define
>> which version the server speaks, and this will become more
>> complicated if you want to make a call to multiple services at one
>> time.
>
> We have all the same problems if an empty string is suddenly valid for
> coordinate systems.  The difference is that overloading is easier for
> the end-user to understand.  And it is easy to parse.

But ADQL-2.0 mandated the protocols using its language to define the set
for <coordsys> from STC/s and TAP did it allowing optional frame, reference
pos and flavour. To me this means that going to an empty string there is not
so new.

Anyway, also on this, the implementation notes tells we need more discussion
on this before putting it in even a minor version, let's have this discussed in
the oncoming session tomorrow afternoon.

Marco