Re: BUG #3751: Conversion error using PreparedStatement.setObject()

Kris,

Thanks for the follow up.

Kris Jurka wrote:
> Lance J. Andersen wrote:
>> Thank you for your time, but i think there is still a driver issue here:
>>
>>
>> If i use the same types as i sent in the email and execute
>>
>> select * from bit_in_min(1::bit)
>>
>> I have no problems and the table is correctly updated.
>>
>> This would lead me to believe that the driver has a problem with
>> correctly mapping the setObect() of the String to a BIT which is
>> required conversion by the JDBC spec.
>>
>
> According to our reading of the JDBC spec java.sql.Types.BIT and
> BOOLEAN are equivalent. So it doesn't make sense to map BIT to one
> server type and BOOLEAN to another. When thinking about Types.BIT
> it's easy to see a server type named "bit" and assume it's a match,
> but for the semantics of Types.BIT, we think boolean is a better match.
The table in this case that needs to be looked at is B-5, not B-4 which
i believe you are referring to. The expectation of
setObject(int/String, Object, int) is that you are sending the value to
the backend as the SQL Type specified for the 3rd parameter, in this
case a BIT.

I would expect that the driver can do the conversion in this case
because i have the table created with a BIT(1) column and the backend
supports both BIT and BOOLEAN.

13.2.2.2 of the JDBC 3.0 and 13.2.2.3 of the JDBC 4.0 spec tries to
make this clear that an explicit conversion is required.

For the JDBC 4.1 spec, i plan to add additional clarifications, but i
would expect the setObject() call in the test to succeed based on the
current spec.

>
> http://archives.postgresql.org/pgsql-jdbc/2004-04/msg00107.php
>
> Just because "bit" can be made to work doesn't make it the best
> option. Particularly our concern arises from what to do when
> returning meta data.
Can you describe this in more detail as I have not noticed a problem via
ResultSetMetaData or DatabaseMetaData.getColumns() as the columns
indicate they are a BIT with the correct precision.
> Consider a table that has columns "a bit(1), b bit(2)". While a does
> have boolean semantics because it's limited to a length of 1, b is
> not. Returning b as Types.BIT would be a mistake. Driving this
> decision solely on the length attribute is not good because the server
> will not give you the length information in certain circumstances and
> all you'll have is the raw "bit" type name. This is why we've chose
> to use boolean as the server type for Types.BIT + BOOLEAN.
Given you support both types, I would expect that if a user wanted to
coerce to a given data type that they would use the 3 parameter version
of setObject() and the rules defined in 13.2.2.3 and B-5 would be followed

Regards
Lance
>
> Kris Jurka