TAPRegExt function declaration [was: ADQL polymorphic functions]

[Grégory Mantelet]

Dear Markus and DAL,

It is indeed a nice simplification that would work for these use-cases. 
I actually did not think to this as a solution when I mentioned it :D

I just hope it won't break anything though...but as said, it is just 
informative for clients/users, so I don't see how it could break 
something. I would have to adapt a bit VOLLT/ADQL-Lib to make it works 
completely with this simplified "type system" (i.e. 'string' and 
'numeric' would work in the current state but not 'geometry' and 'any') 
so that the query check process of TOPCAT works as expected. But that 
would apparently be a trivial modif. on my side.

So, it's ok for me. And if ok for others as well, I am totally fine with 
you, Markus, to write this PullRequest.

Cheers,
Grégory


On 23/04/2021 18:10, Markus Demleitner wrote:
> Dear Grégory,
>
> [restricting to DAL, as this is becoming rather DAL-specific]
>
> On Fri, Apr 23, 2021 at 10:37:03AM +0200, Grégory Mantelet wrote:
>>       not the best one.
>>       An alternative could be to introduce special types like:
>> ANY, ANY_NUMERIC, ...
>>
>> About datatypes in UDF signature, for the moment, nothing specifies what
>> datatypes are allowed. And this is especially the case in ADQL, where there
>> is
>> no strong typing.
>>
>> Personally, when reading such datatypes, my ADQL parser simplifies them as
>> "numeric", "string", "geometry" and "unknown" (a synonym of "any") in order
>> to
>> check types ; it allows it to make a simple query check with approximate
> You know -- shouldn't we just adopt this as the recommended type
> system (with "any" instead of "unknown")?  I *think* that's covering
> the use cases we have for the signatures, and it's nice and simple.
>
> I'd totally support an issue to this effect against
> https://github.com/ivoa-std/TAPRegExt.  I'd even write a PR unless
> you want to.
>
> Thanks,
>
>          Markus