Just to follow up on something I said below... On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole <st...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev