On Nov 6, 2003, at 6:09 PM, Oliver Jowett wrote:
> There's a patch pending that should fix this problem .. it adds an
> explicit
> typecast to all literals that reflects the type provided to JDBC
> (either
> implied by the method used, or from the java.sql.Types value for
> setObject()). So the above query actually turns into:
>
> SELECT COUNT(*) FROM foo WHERE (id=1234::int8)
>
> if you use setLong() or setObject(..., Types.BIGINT) to set the
> parameter.
>
> This does break other cases (e.g. using setLong() when you actually
> want an
> int4 value) but it's necessary to get consistency between the PREPARE
> and
> non-PREPARE paths.. and it's almost an application error in this case
> anyway.
>
This sounds like a good fix. It was unfortunate that the additional
type info that the PreparedStatement knew was evaporating before it
could be used by the backend to stop some maddness. JBoss does indeed
use the setObject(..., Types.BIGINT) (see line 1278 of
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil -- that was fun to ultimately
track down), so that should keep it happy.
Thanks!
----
James Robinson
Socialserve.com
