From: | "Jon Raiford" <raiford(at)labware(dot)com> |
---|---|
To: | "Clemens Ladisch" <clemens(at)ladisch(dot)de> |
Cc: | pgsql-odbc(at)lists(dot)postgresql(dot)org |
Subject: | Re: Report BUG: The column size for BIT VARYING(5) type is incorrect |
Date: | 2020-08-27 14:42:52 |
Message-ID: | OFAF7AB175.419F748F-ON852585D1.004F51A9-852585D1.0050D836@labware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
"Clemens Ladisch" <clemens(at)ladisch(dot)de> wrote on 08/26/2020 03:01:20 AM:
> > Why is the *ColumnSizePtr = 1 instead of *ColumnSizePtr = 5 since
> the column is created with bit varying (5) in the test case?
>
> The ODBC specification does not define the data type BIT VARYING, so the
> ODBC driver tries to represent it as a blob or text.
>
> And five bits fit into one byte.
I'm not sure this is the correct interpretation. According to PostgreSQL,
bit varying(n) is a bit "string" (
https://www.postgresql.org/docs/12/datatype-bit.html) The ODBC spec says
that the column size for all string types is defined as the "... maximum
column size in characters of the column or parameter" (
https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/column-size
). Also, according to the bug report, SQLDescribeCol answered that the
data type in this case was returned as SQL_WVARRCHAR.
I don't use this type myself but based on the documentation and the
(fact?) SQLDescribeCol answers the type as SQL_WVARCHAR, it does make
sense to me for the column size to match the number of characters needed
to represent the bits.
Jon
From | Date | Subject | |
---|---|---|---|
Next Message | WAN, RUIWEN | 2020-08-31 21:50:18 | PostgreSQL ODBC Driver to access Oracle/MSSQL from PostgreSQL |
Previous Message | Clemens Ladisch | 2020-08-27 06:48:41 | Re: Source or binaries for pgsql-odbc for Linux (Amazon Linux 2) |