The ProcedureCall support for this is already mostly in place. To call a function named fn_count_comments you'd do something like:

ProcedureCall call = session.createStoredProcedureCall( "fn_count_comments" );
// an inherent "parameter #0" registration
call.markAsFunction( Types.INTEGER );
call.registerParameter( 1, Integer.class, IN );

The only part still not completely determined is exactly how to access the return value upon execution. Do we access that through the existing `#getOutputParameterValue` approach? That is the approach that will work "seamlessly" with JPA usage + hint. So that would look like:

call.execute();
final Integer commentCount = call.getOutputParameterValue( 0 );

In 6.0, ProcedureCall (Hibernate) extends StoredProcedureQuery (JPA) so we will for sure have consistent support both via an explicit call as well as a hint. In terms of a series of pure JPA calls, however, this comes off a little bit awkward:

StoredProcedureQuery spq = em...;
// again, an inherent "parameter #0" registration
spq.setHint( "hibernate.procedure.function_return_jdbc_type_code", Types.INTEGER );
call.registerStoredProcedureParameter( 1, Integer.class, IN );

Your PostgreSQL comment is actually a 3rd concern, encapsulated in org.hibernate.procedure.spi.CallableStatementSupport#shouldUseFunctionSyntax. Essentially PostgreSQL supports REF_CURSOR but in a very very very specific way..

Really this is something we need to consider in a few distinct, albeit related, parts...

1. Which JDBC "call form" do we use? ` {call it(...)}

   ` or `{?=call it(...)}`

2. How are the return v. parameters registered?
3. How are the out values accessed between return v. parameters?