I noticed that AbstractQueryImpl.setParameter(i, object) falls back to the Serializable type immediately if the input parameter is null. This can cause DB-specific problems, such as "ERROR: operator does not exist: character varying = bytea" with PostgreSQL. (The untyped setParameter(i,obj) method is used heavily from Spring's HibernateTemplate class, which calls it from find(string query, obj param) methods.)

Since the parameter types in HQL are known a priori, though, it seems like AbstractQueryImpl could guess the object type based on context even if the value itself is null, and then fall back to Serializable later if no type can be guessed from context. (reference:
http://opensource.atlassian.com/project ... e/HHH-1129
)



To verify this approach, I made a simple example ("from foo where bar = ?" with bar as a String) and took out the two lines in AbstractQueryImpl that fall back to Serializable. Then, StringType was correctly guessed even if the input is null.

Should I open this as a feature/enhancement request on JIRA?

Hibernate version: 3.1.3

Code between sessionFactory.openSession() and session.close():



Full stack trace of any exception that occurs:
PSQLException: ERROR: operator does not exist: character varying = bytea

Name and version of the database you are using: PostgreSQL 8.x

Debug level Hibernate log excerpt:
DEBUG AbstractBatcher [http-8088-Processor4] 10 Jul 2006 09:33:09: preparing statement DEBUG SerializableType [http-8088-Processor4] 10 Jul 2006 09:33:09: binding null to parameter: 1

Duhh .. surprisingly this is never answered .. did you get a solution because now i face the same problem but with oracle.

you should use

"from foo where bar is null"