What happened
For a legal MySQL INVISIBLE user column, Dolt expands t.* to include the hidden column. The window value itself is correct, but the result schema and row shape are wrong.
Environment
Dolt main (commit c3b5ce3c67f8677ca08a0a58d8c03cdc95bff8b7). MySQL version 8.0.43.
How to reproduce
Run the corresponding SQL in a fresh Dolt repository.
CREATE TABLE t(
id INT PRIMARY KEY,
hidden INT INVISIBLE,
g INT NOT NULL,
k INT NOT NULL,
v INT NOT NULL
);
INSERT INTO t(id,hidden,g,k,v) VALUES
(1,99,0,2,10),
(2,98,0,1,20),
(3,97,1,1,30);
SELECT t.*,
ROW_NUMBER() OVER (PARTITION BY g ORDER BY k,id) AS rn
FROM t
ORDER BY id;
Expected Result
MySQL documents that * and tbl_name.* do not include an INVISIBLE column; an invisible column must be named explicitly. See the MySQL 8.4 SELECT documentation and MySQL invisible-column documentation.
The independent exact-INT expected result is therefore:
id g k v rn
1 0 2 10 2
2 0 1 20 1
3 1 1 30 1
The ROW_NUMBER ordering is (g, k, id), so the first two rows have row numbers 2 and 1; the INVISIBLE column is absent from the projection.
Actual Result
Dolt returned:
id hidden g k v rn
1 99 0 2 10 2
2 98 0 1 20 1
3 97 1 1 30 1
What happened
For a legal MySQL
INVISIBLEuser column, Dolt expandst.*to include the hidden column. The window value itself is correct, but the result schema and row shape are wrong.Environment
Dolt main (commit
c3b5ce3c67f8677ca08a0a58d8c03cdc95bff8b7). MySQL version 8.0.43.How to reproduce
Run the corresponding SQL in a fresh Dolt repository.
Expected Result
MySQL documents that
*andtbl_name.*do not include anINVISIBLEcolumn; an invisible column must be named explicitly. See the MySQL 8.4 SELECT documentation and MySQL invisible-column documentation.The independent exact-INT expected result is therefore:
The
ROW_NUMBERordering is(g, k, id), so the first two rows have row numbers2and1; theINVISIBLEcolumn is absent from the projection.Actual Result
Dolt returned: