|
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.
|