RegTAP Post-RFC: aggregate functions
Menelaus Perdikeas
mperdikeas at sciops.esa.int
Fri May 23 06:25:45 PDT 2014
At ESAC we're relying on TAP library by Grégory Mantelet for ADQL parsing / translation to SQL so if translating ivo_string_agg to PostgreSQL's string_agg can be done by the library I guess it's pretty much transparent to us.
The same applies to array_agg (although I must confess being a bit more cautious/reserved with that function and the array data type it returns). But my feeling is that it, too, would be contained in the TAP library and not spill out.
Cheers,
Menelaus.
----- Original Message -----
From: "Markus Demleitner" <msdemlei at ari.uni-heidelberg.de>
To: registry at ivoa.net
Sent: Wednesday, May 21, 2014 9:29:56 PM
Subject: RegTAP Post-RFC: aggregate functions
Dear list,
as promised, here's the third and for now last installment of the Post-RFC
consultation on RegTAP based on today's talk
http://wiki.ivoa.net/internal/IVOA/InterOpMay2014Registry/regtaprfc.pdf
So, this is about requiring UDFs analogous to postgres' string_agg
or array_agg for RegTAP, like we now require ivo_nocasematch and
friends.
What these guys do is best illustrated by an example:
(this wants a wide window to be fully enjoyed):
$ tapsh
[...]
tapsh> server ivo://org.gavo.dc/__system__/tap/run
tapsh> select top 4 ivoid, ivo_string_agg(res_subject, ', ') from rr.resource natural join rr.res_subject group by ivoid!
ivoid asbdwbu
ivo://3crsnapshots Radio Galaxies
ivo://3crsnapshots/sia Radio Galaxies
ivo://adil.ncsa grid-based processing, digital libraries, data repositories, radio astronomy
ivo://adil.ncsa/adil digital libraries, data repositories, radio astronomy
-- so, basically, you glue together items from 1:n relationships.
Postgres also can do this with arrays, but given that string arrays
su^H^Hhave undesirable properties in VOTable, I suspect this --
although even more useful in principle -- wouldn't quite work as
well.
I've not put that into the RegTAP from the start since I was too lazy
to see if ADQL syntactically lets you do user defined aggregate
functions (it does) and I wasn't sure how well supported this is in
the underlying databases.
On the other hand, in actual client implementations, these beasts
have proven very useful and ADQL didn't mind them syntactically, so
I'd like to propose inclusion if no objections are voiced. Even
feeble objections, I'd say, are enough in this case, as this
obviously is a new feature and, if it went in, a demand for a new RFC
could probably not go unheeded.
Thanks in advance for any kind of feedback, and again if you are in
Madrid and you have any opinion on any of the issues raised, please
talk to me.
Cheers,
Markus
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
More information about the registry
mailing list