Just to follow up on something I said below...
On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole <steve(a)hibernate.org> wrote:
Right, that would mean adjusting SQLFunction to report whether the
arguments are "varargs". I plan on looking to change the SQLFunction
contract quite a bit already actually. Today we render these (into the
SQL) via the method `String render(Type argumentType, List args,
SessionFactoryImplementor factory)` where the `args` is List<String>. I'd
prefer that to be more OO than String. In terms of SQM and SQL-tree, I'd
like that to be something like List<SqlTreeExpression>. Heck I'd love for
these SQLFunctions themselves to implement SqlTreeExpression themselves and
embed them directly into the SQL-tree
This whole discussion about the SQLFunction contract change is not really
related to this discussion. I was just pointing out that I already have
some changes in mind for that contract. So changing the contract for this
is not a "hardship".
I forget the details atm, I just know that I have been in situations when
writing a SQLFunction impl where it would have been nice to know some more
details about a particular argument - especially when you start thinking
about nested function calls.