Actually JPA defines it as "Only positional parameter binding and
positional access to result items may be portably used for native queries".
I believe "portably" means the providers are only required to support
positional, but not forbidden from supporting other.
2016-09-21 3:59 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
In the interest of questioning everything, just to make sure we are
the same page, Hibernate's support for native SQL queries currently
recognizes named parameters, positional parameters as well as JDBC-style
JPA only defines support for "JDBC-style parameters" as valid for native
It is assumed that for native queries the parameters themselves use the SQL
syntax (i.e., “?”, rather than “?1”).
Furthermore Hibernate does not support a native query using both positional
parameters and JDBC-style parameters in the same query because it causes a
non-determinism wrt the positions.
I assume we want to continue to support that full complement of parameter
types, with the positional/JDBC-style caveat.
Further I assume we will hook up the use of any non-JDBC-style parameters
in with the "strict JPA compliance" checking and throw an error when
Anyone have objections to any of that?
hibernate-dev mailing list