Hi Noel, Thanks for your response.
(1) is creative :) I'd have to do this for both JDBC types and H2 internal types, I guess... I'm actually not even sure if I can assume to be able to load the aggregate function implementation class from where I'd be doing this, so I'd have to probe the function signature with SQL statements. As you suggested, degree 2+ is out of scope for such testing due to combinatorial complexity. (2) would indeed be a solution, if such AggregateMetadata would then be used to fill INFORMATION_SCHEMA tables. I guess the "burden" on the user implementing such functions is acceptable, given that writing user-defined aggregate functions is not a very common task. I wonder though, if H2 could imitate HSQLDB in this matter: http://hsqldb.org/doc/guide/guide.html#src_jrt_aggregate_functions Having an aggregate function map to a single static method is also closer to what H2 already does for "ordinary" functions (rather than the current mapping to an interface implementation). Unfortunately, the SQL standard still doesn't seem to specify how user-defined aggregate functions should be implemented, but HSQLDB is usually very close to the standard... What do you think? This could be viewed as a long-term improvement, as HSQLDB also supports INOUT and OUT parameters through Java arrays on "regular" procedures. Best, Lukas Am Dienstag, 1. Juli 2014 09:11:00 UTC+2 schrieb Noel Grandin: > > > > 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.
