Type inference for function arguments

[sebersole]

Consider (from https://hibernate.atlassian.net/browse/HHH-10463):

Query query = session.createQuery("from Person p where p.name = coalesce(:name, p.name) ");
query.setParameter("name", null);

At the moment this query will fail. It fails because it does not figure out how to handle the null parameter value.

Here, we do not (re)set the expected type for the parameter based on the resolved type for the function. There are a number of factors in play here. The SelfRenderingSqmFunction and FunctionReturnTypeResolver stuff simply does not handle this situation. Here we try to use the first non-null argument node-type as the type for the overall coalesce function type. The first arg (param) has a null type, so we go to the second which has a type so we use that. In-and-of-itself, that is fine. However, coalesce has an implicit contract that all of the arguments need to be of the same type. Here, we should treat the param type as that for the overall function type (as determined from the second argument type).

We either need to recognize this while building the SQM or translating the SQM to SQL-AST, but it ends up that we cannot currently do that in either case.

== As part of SQM building

As we walk the arguments and come to that second argument, in theory we should go back and (re)set the anticipated for the parameter. However, SqmTypedNode does not define a way to (re)set the node type. So there is currently not a way to do this in the SQM builder.

To handle this as part of SQM building, we'd need to make the type associated with a SqmTypedNode resettable.

== As part of SQM translation

The way this is intended to work is the inferable type handling within the translator. Here, we'd start processing the coalesce function and push its type to the inference stack. However (1) this is specific to coalesce (most functions do not have this behavior) and (2) functions are all handled by the same piece of code so it is impossible to add such function specific handling.

To handle this as part of the translation, the best solution imo would be to handle this as part of the type-inference handling. But that would (dangerously) require exposing push/pop capability for the inferrableTypeAccessStack. But even then, I'm not sure how we'd handle the function-specific aspects.

== Type precedence

There is also another, related concern in that this argument type resolution might miss a "higher precedence" type. Consider this instead:

Query query = session.createQuery( "from Person p where p.name = coalesce( :name, p.name )" );
query.setParameter( "name", "Steve" );

Now, we can determine a type for the parameter based on the bind value. Since that is the first argument and because coalesce is defined to use the first non-null argument we will use that type as the result of the function. The problem? What if p.name is a converted value? If so, its type should always be used.

Stated more generally, given a choice between 2 types, the pathed-type should always have precedence.

[beikov]

I think this should happen during SQM translation. Maybe we could even add some API for allowing a function to control the inference?

[gavinking]

(I mean that's a feature I've been wanting to add for a long time now.)

[gavinking]

Actually I suppose I should start a separate discussion about that issue.

[sebersole]

Actually I think that belongs here - its just part of inferring argument types

[gavinking]

OK fine, they're certainly closely related.

[beikov]

I implemented type inference during SQM to SQL Ast conversion. See the PR for details: #4807