| Author |
Why is bool == java.sql.Types.BIT ??
|
|
| Thomas Kellerer 2005-11-23, 1:28 pm |
| Hello,
I noticed that table columns that are defined as "bool" (Postgres
datatype) are reported as java.sql.Types.BIT through DatabaseMetadata
(or ResultSetMetaData).
Is there any valid reason why they are not reported as
java.sql.Types.BOOLEAN?
Regards
Thomas
---------------------------(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
| |
| Kris Jurka 2005-11-23, 1:28 pm |
|
On Wed, 23 Nov 2005, Thomas Kellerer wrote:
> I noticed that table columns that are defined as "bool" (Postgres datatype)
> are reported as java.sql.Types.BIT through DatabaseMetadata (or
> ResultSetMetaData).
>
> Is there any valid reason why they are not reported as
> java.sql.Types.BOOLEAN?
>
Because BOOLEAN is only available to JDBC3. Our driver still supports
JDBC2 so we use BIT. BOOLEAN and BIT are the same thing as far as we can
tell.
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
| |
| Andres Ledesma 2005-11-23, 1:28 pm |
|
Hi Thomas :
Long ago I had the same doubt. The reason is first versions of JBDC associated
the Types.BIT to the boolean of SQL, and is keeped this way for compatibility
reasons, I think.
-
Andres Ledesma
=================
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Thomas Kellerer 2005-11-23, 8:24 pm |
| Kris Jurka wrote on 23.11.2005 19:41:
>
> Because BOOLEAN is only available to JDBC3. Our driver still supports
> JDBC2 so we use BIT. BOOLEAN and BIT are the same thing as far as we
> can tell.
Makes sense. I knew there was a reason :)
The problem comes when supporting multiple DBMS. With MS SQL Server a
bit column can only store 0/1 (which is not what the driver returns, as
it uses a java.lang.Boolean) but PG only accepts the literals
true/false. That's why I stumbled over this in the first place.
So I'll have to check the native type rather then the JDBC type to be sure.
Regards
Thomas
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Oliver Jowett 2005-11-23, 8:24 pm |
| Thomas Kellerer wrote:
> The problem comes when supporting multiple DBMS. With MS SQL Server a
> bit column can only store 0/1 (which is not what the driver returns, as
> it uses a java.lang.Boolean) but PG only accepts the literals
> true/false. That's why I stumbled over this in the first place.
>
> So I'll have to check the native type rather then the JDBC type to be sure.
Can't you use setBoolean()/getBoolean()? I think that's specified to
always work on a BIT column, whatever the real underlying type is.
-O
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Thomas Kellerer 2005-11-24, 11:23 am |
| Oliver Jowett wrote on 24.11.2005 00:50:
> Thomas Kellerer wrote:
>
>
>
> Can't you use setBoolean()/getBoolean()? I think that's specified to
> always work on a BIT column, whatever the real underlying type is.
>
Yes of course I can and actually I do when using PreparedStatements
But when I'm generating SQL Scripts I need to use the correct literal
for such a column.
Regards
Thomas
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
| |
| Oliver Jowett 2005-11-24, 8:24 pm |
| Thomas Kellerer wrote:
> Oliver Jowett wrote on 24.11.2005 00:50:
>
>
> Yes of course I can and actually I do when using PreparedStatements
> But when I'm generating SQL Scripts I need to use the correct literal
> for such a column.
Well, if you're going to bypass the abstractions that JDBC gives you to
deal with this sort of case, of course you will end up with
DBMS-specific code..
-O
---------------------------(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
|
|
|
|