Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0.1
Description
-
-
- Problem Description
The ZEROFILL display metadata is not consistently preserved during expression/subquery/derived table propagation. Direct access to a `DOUBLE UNSIGNED ZEROFILL` column retains leading zeros; however, when the value is produced by a scalar subquery inside a derived table, the ZEROFILL display attribute is lost. This affects functions that depend on the string representation, such as `LOCATE` and `ORD`, leading to different results.
- Problem Description
-
-
-
- How to Reproduce
Execute the following SQL:
- How to Reproduce
-
```sql
DROP DATABASE IF EXISTS repro_mariadb805_db3_min;
CREATE DATABASE repro_mariadb805_db3_min;
USE repro_mariadb805_db3_min;
CREATE TABLE source_base (
c0 DOUBLE UNSIGNED ZEROFILL DEFAULT NULL
) ENGINE=MyISAM;
INSERT INTO source_base VALUES (234567890);
CREATE TABLE vp_source LIKE source_base;
ALTER TABLE vp_source ADD COLUMN vp_rowid BIGINT NOT NULL;
INSERT INTO vp_source (vp_rowid, c0)
SELECT ROW_NUMBER() OVER (ORDER BY c0), c0
FROM source_base;
CREATE TABLE vp_left (
vp_rowid BIGINT NOT NULL
) ENGINE=MyISAM;
CREATE TABLE vp_right (
vp_rowid BIGINT NOT NULL,
c0 DOUBLE UNSIGNED ZEROFILL DEFAULT NULL
) ENGINE=MyISAM;
INSERT INTO vp_left
SELECT vp_rowid FROM vp_source;
INSERT INTO vp_right
SELECT vp_rowid, c0 FROM vp_source;
SELECT 'DIRECT' AS variant,
c0,
LOCATE(false, c0) AS locate_result,
ORD(ORD(c0)) AS value
FROM vp_source
WHERE LOCATE(false, c0);
SELECT 'RECONSTRUCTED' AS variant,
c0,
LOCATE(false, c0) AS locate_result,
ORD(ORD(c0)) AS value
FROM (
SELECT l.vp_rowid,
(
SELECT r.c0
FROM vp_right r
WHERE r.vp_rowid = l.vp_rowid
) AS c0
FROM vp_left l
) AS reconstructed
WHERE LOCATE(false, c0);
```
-
-
- Expected Behavior
The direct query and the reconstructed query should produce identical results:
- Expected Behavior
-
| variant | c0 | locate_result | value |
| --------------- | ------------------------ | --------------- | ------- |
| DIRECT | 0000000000000234567890 | 1 | 52 |
| RECONSTRUCTED | 0000000000000234567890 | 1 | 52 |
-
-
- Actual Behavior
The reconstructed query loses the ZEROFILL leading zeros, causing the function results to change:
- Actual Behavior
-
| variant | c0 | locate_result | value |
| --------------- | ----------- | --------------- | ------- |
| DIRECT | 0000000000000234567890 | 1 | 52 |
| RECONSTRUCTED | 234567890 | 9 | 53 |
Detailed comparison:
| Expression | Direct Query | Reconstructed Query |
| -------------------- | ------------------------ | --------------------- |
| `c0` display value | `0000000000000234567890` | `234567890` |
| `LOCATE(false,c0)` | `1` | `9` |
| `ORD(ORD(c0))` | `52` | `53` |
-
-
- Additional Analysis
-
- Direct read of ZEROFILL column: string representation = `'0000000000000234567890'`.
- After passing through scalar subquery/derived table: string representation = `'234567890'`.
- This is not a numeric storage error, but a loss of ZEROFILL display metadata during expression/subquery/derived table propagation.
Attachments
Issue Links
- relates to
-
MDEV-12407 Different representation of bit values depending on presence of views and derived tables
-
- Confirmed
-
-
MDEV-39117 UNION does not preserve ZEROFILL
-
- Confirmed
-
-
MDEV-40911 Binary-protocol prepared-statement parameter resolves to the legacy ..._general_ci default collation after character_set_client is restored via a standalone SET CHARACTER_SET_CLIENT = <user-variable> statement
-
- Confirmed
-