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.
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. 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.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
