ADQL-2.1 internal draft

[Marco Molinaro]

Hi Walter,

2015-06-12 20:42 GMT+02:00 Walter Landry <wlandry at caltech.edu>:
> Marco Molinaro <molinaro at oats.inaf.it> wrote:
>> 2015-06-11 0:05 GMT+02:00 Walter Landry <wlandry at caltech.edu>:
>>> I am not suggesting removing the 2.0 version with a coordinate system.
>>> I am suggesting adding an overload and not having an implicit meaning
>>> for an empty string.  That would retain the property of the current
>>> proposal that all 2.0 queries are valid in 2.1, but not all 2.1
>>> queries are valid in 2.0.
>>
>> but while function overload is managed by postgresql, it's not in
>> MySQL -e.g.-.
>
> The guy down the hall from me who hacks on MySQL says he does this
> exact thing all the time.  This link
>
>   https://dev.mysql.com/doc/refman/5.1/en/udf-arguments.html

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.

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.

<cut>
>> That's why ASCII was considered to be enough.
>
> Looking at the Unicode spec, despite the example I gave before with ϱ,
> it recommends case folding by lower casing everything.  Weird.  In any
> case, if I implemented LOWER(), then implementing UPPER() would be
> trivial.  In general, I do not like this idea of restricting the usage
> of case-insensitivity functions to UCD's and Utypes.  We should put
> them in for general use or not put them in at all.

My concern is: do we really need them for general use? Or were they only asked
for some specific one.
Given case sensitiveness is not a painless thing, I'd prefer avoiding
unnecessary
trouble.
We can reserve lower/upper/ilike, if dal agrees, and then define what
is mandated
or not for them.
Repeating myself: I'm concerned introducing something only because we can do it,
this feature seems to come from a specific use case.

Cheers,
     Marco