On 2014-06-28 09:13 AM, Lukas Eder wrote:
H2's aggregate functions are not "type safe" in that way, so a single aggregate
function implementation can handle all
sorts of combinations for "return type / input arity / input types". In my
opinion, that's why it cannot be reported
correctly through the INFORMATION_SCHEMA...
Yeah, you're right, it's not ideal for your use-case.
Hmmm. I'm not terribly inclined to make the existing API more complicated, but
I see your problem.
I can suggest two things
(1) You assume arity of one, and you probe the return types of the aggregate functions using SQL statements, for each
aggregate looping through all of the SQL data types for the parameter.
(2) we create a new interface AggregateMetadata that returns the necessary information which people can optionally
implement.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
