Skip site navigation (1) Skip section navigation (2)

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

From: "Lance J(dot) Andersen" <Lance(dot)Andersen(at)Sun(dot)COM>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3751: Conversion error using PreparedStatement.setObject()
Date: 2007-11-16 15:46:40
Message-ID: 473DBB60.4050202@sun.com (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2007-11-16 16:00:14
Subject: Re: BUG #3752: query yields "could not find block containing chunk", then server crashes
Previous:From: Heikki LinnakangasDate: 2007-11-16 11:08:49
Subject: Re: B-tree crash recovery error in 8.3 beta 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group