Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11.3, 11.0.2, 10.4.29, 10.5.20
-
None
Description
MariaDB [test]> CREATE TABLE t_odbc350 (v BIT(1)); |
Query OK, 0 rows affected (0.045 sec) |
|
MariaDB [test]> INSERT INTO t_odbc350 VALUES(0); |
Query OK, 1 row affected (0.103 sec) |
|
MariaDB [test]> SELECT v, (SELECT v FROM t_odbc350 LIMIT 1) FROM t_odbc350; |
Field 1: `v` |
Org_field: `v`
|
Catalog: `def`
|
Database: `test`
|
Table: `t_odbc350`
|
Org_table: `t_odbc350`
|
Type: BIT
|
Collation: binary (63) |
Length: 1 |
Max_length: 1 |
Decimals: 0 |
Flags: UNSIGNED
|
|
Field 2: `(SELECT v FROM t_odbc350 LIMIT 1)` |
Org_field: ``
|
Catalog: `def`
|
Database: ``
|
Table: ``
|
Org_table: ``
|
Type: BIT
|
Collation: binary (63) |
Length: 1 |
Max_length: 1 |
Decimals: 0 |
Flags: UNSIGNED BINARY
|
|
+------+-----------------------------------+
|
| v | (SELECT v FROM t_odbc350 LIMIT 1) | |
+------+-----------------------------------+
|
| | 0 | |
+------+-----------------------------------+
|
1 row in set (0.000 sec) |
The metadata suggests that the (second) field type is BIT, but the value is server returns is '0' or '1'. I tried with bit(n>1) fields - same story. There is small difference in metadata between 1st and 2nd field - binary flag. I don't know - maybe that is all intended behavior, but does not look right for me. I didn't try with 10.4, but I believe it's in all versions. In CLI output it's not really visible, that the value is '0', but I checked in debugger - these are the values coming from server. The only thing - I checked using binary protocol, but I think it's the same for text.
Attachments
Issue Links
- relates to
-
ODBC-350 Invalid BIT column value from subselect
- Closed