TAPRegExt function declaration [was: ADQL polymorphic functions]

[Mark Taylor]

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.

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/