[CONC-563] Incorrect handling of max_column size sent by server to client in Column definition packet Created: 2021-07-26  Updated: 2021-07-26  Resolved: 2021-07-26

Status: Closed
Project: MariaDB Connector/C
Component/s: Prepared Statements
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Dmitry Shulga Assignee: Georg Richter
Resolution: Duplicate Votes: 0
Labels: None


 Description   

Running the following MTR test case

CREATE TABLE t1(f1 YEAR(4));
INSERT INTO t1 VALUES (0000),(2001);
--enable_metadata
(SELECT MAX(f1) FROM t1) UNION (SELECT MAX(f1) FROM t1);
--disable_metadata
DROP TABLE t1;

leads to test failure in case it is run with the option --ps-protocol with the following diagnostic message:

@@ -2,7 +2,7 @@
 INSERT INTO t1 VALUES (0000),(2001);
 (SELECT MAX(f1) FROM t1) UNION (SELECT MAX(f1) FROM t1);
 Catalog	Database	Table	Table_alias	Column	Column_alias	Type	Length	Max length	Is_null	Flags	Decimals	Charsetnr
-def				MAX(f1)	MAX(f1)	13	4	4	Y	32864	0	63
+def				MAX(f1)	MAX(f1)	13	4	6	Y	32864	0	63
 MAX(f1)
 2001
 DROP TABLE t1;
 
mysqltest: Result content mismatch

Running above mentioned test under debugger shows that resultset metadata in Server Response packet is set correctly.

Discussion of this issue with Georg discovered surprising thing - Max column size sent in Response packet is ignored and actual value is calculated based on constants initialized in the function mysql_init_ps_subsystem().

It seems such implementation is good candidate for rewriting.



 Comments   
Comment by Georg Richter [ 2021-07-26 ]

Duplicate of CONC-564

Generated at Thu Feb 08 03:06:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.