Started looking at this today, specifically in terms of 2 issues:

1. Determining the proper call syntax. Should the call SQL be rendered as {call the_name(...)} versus {?=call the_name(...)}
2. Fitting definition and handling of the function return into JPA Parameter API. The main issue here is the "undefined" nature of mixing named and positional parameter registrations as part of StoredProcedureQuery. If StoredProcedureQuery is using just positional parameters for a function call then there is no issue. The problem comes when trying to use named parameter registrations for the function call. Basically the safest bet is to keep a separate reference to the "function return".

Also of concern is how much effort to put into making the JPA StoredProcedureQuery API work as-is for function calls versus assuming that users will have to make Hibernate-specific calls. As I said above, I think that handling the "function return" separately from parameter registrations is the best approach; but that will require Hibernate-specific calls. JPA users would need to cast StoredProcedureQuery (via #unwrap) to the Hibernate ProcedureCall and register the function return via that API:

interface FunctionReturn<T> extends ParameterRegistration<T> {
    ...
}

interface ProcedureCall {
    ...
    <T> FunctionReturn<T> registerFunctionReturn(Class<T> type, boolean isRefCursor);
}

As is, the above would not be accessible via JPA parameters.

WDYT?