TAPRegExt function declaration [was: ADQL polymorphic functions]

[Grégory Mantelet]

On 26/04/2021 13:16, Mark Taylor wrote:
> I don't do anything with these signatures except (a) present them
> as unparsed text to users and (b) pass them to VOLLT, to aid it
> in parsing ADQL.  So no problems from my side, except maybe backward
> compatibility issues if they are encountered by a TOPCAT installation
> with a VOLLT version predating this proposal.
> Grégory may be able to comment on whether that's something to worry about.


Currently I support a wide variety of datatypes in there, and I just 
convert them into these simplified types. What I plan to do if we go for 
this type system is just to also support 'geometry' and 'any'. So, 
nothing to worry about with backward compatibility, I think.


> On Mon, 26 Apr 2021, Grégory Mantelet wrote:
>
>> 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
>>
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/