ADQL polymorphic functions

[Markus Demleitner]

Hi Mark,

On Thu, Apr 22, 2021 at 05:44:59PM +0100, Mark Taylor wrote:
> On Thu, 22 Apr 2021, Markus Demleitner wrote:
> >   SELECT access_url, gavo_specconv(em_min, 'keV') as en_min
> >   FROM ivoa.obscore
> >   WHERE 1=CONTAINS(s_region, CIRCLE(30, 20, 5))
> >     AND gavo_specconv(1, 'keV', 'm') BETWEEN em_min and em_max
> 
> A function with an optional argument *in between* two mandatory arguments
> looks ... quite surprising to me.  It's a sufficiently strange/confusing

The "inserted optional parameter" is a pattern that is, I think,
surprisingly common; think of python's range builtin that comes as
range(stop) or range(start, stop[, step]).  And while this isn't
pretty, I'd argue having it any other way would be a lot less pretty.

But the question where to put the optional parameter in this
particular UDF I'd like to defer to a different (future) thread.

> for non-stupidly-verbose names in this case, but maybe it would just
> be better to have a single 3-parameter version and allow an empty
> string for the middle parameter.

Ah... that's an interesting idea, too, though "empty string means
infer unit" doesn't feel terribly elegant to me at this point.  But
back to the topic:

> > have to scan (in TOPCAT's service tab, say), and this might become
> > really ugly when functions are highly polymorphous (think: three
> > optional parameters each accepting three types would explode into
> > nine feature elements with, presumably, almost identical content.
> 
> Is that 9-way overload really something you can imagine?

Fair question, and paging through the postgres documentation I notice
that while optional arguments are reasonably common (though less
common than I had estimated), they don't have a lot of type
polymorphism (an interesting one is to_ascii on
https://www.postgresql.org/docs/13/functions-string.html, and
unsurprisingly this comes up with to_char,
https://www.postgresql.org/docs/13/functions-formatting.html).

Perhaps our geometry exercises (with CIRCLE(coosys, ra, dec, radius),
CIRCLE(ra, dec, radius), CIRCLE(center, radius) and perhaps even (I
forget) CIRCLE(coosys, center, radius)) have made me a bit
over-paranoid there.

> Given those comments, the above option of listing the UDF multiple
> times in multiple features elements doesn't sound like it would be
> too burdensome in practice.

Given the results of my informal survey of the postgres docs, I think
I'm leaning that way, too.

> >   <feature>
> >     <form>gavo_specconv(expr DOUBLE PRECISION, dest_unit TEXT) 
> >         -&gt; DOUBLE PRECISION</form>
> >     <form>gavo_specconv(expr DOUBLE PRECISION, expr_unit TEXT, dest_unit TEXT) 
> >         -&gt; DOUBLE PRECISION</form>
> >       <description>returns the spectral value expr converted to dest_unit.
> >         expr is assumed to be given in expr_unit...
> >       </description>
> >   </feature>
> > 
> > -- this would be my favourite, except it needs schema changes in
> > TAPRegExt, and I'd not bet on how well existing capabilities parsers
> > would cope with this.  Conversely, I think some of the other features
> > could profit from allowing multiple form-s, too.  Hm.
> 
> this one seems quite reasonable.  You can also imagine listing multiple
> UDFs with different names alongside each other in this way if it
> was semantically convenient to combine their documentation together.

Given this would, I think, solve this particular problem rather
elegantly, but perhaps is solving something that's much less of a
problem than I had initially felt: Does anyone feel multiple forms
per feature might give us other benefits?

If not, I think for now I'd just have two gavo_specconv features and
think again if my concerns about an inflation of UDF features
actually substantiate.

Thanks,

            Markus