[Inconsistency/Bug] Vector DATA_TYPE parsing inconsistency and I_S versioning leads to MTR failures

[UsedByFeiYang]

Hi ,

I noticed that the parsing logic for DATA_TYPE was recently updated in sql/dd/impl/system_views/columns.cc to support the VECTOR type by stripping comments and dimensions:

cpp

/* Ignore the comment especially for vector columns. */
m_target_def.add_field(FIELD_DATA_TYPE, "DATA_TYPE",
                       "SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX(col."
                       "column_type_utf8, '*/ ', -1), '(', 1),' ', 1)");

While this is a great improvement for COLUMNS, I have found several concerns regarding its implementation:

1. MTR Test Failure (i_s_schema_definition_debug)
After this modification, the MTR test case information_schema.i_s_schema_definition_debug consistently fails with a checksum mismatch.

It appears the I_S_VERSION (or IS_DD_VERSION) was not incremented. This mismatch indicates that the persisted Data Dictionary (DD) definitions are now out of sync with the hardcoded checksums.

2. Missing Adaptations in PARAMETERS and ROUTINES
The logic in sql/dd/impl/system_views/parameters.cc and sql/dd/impl/system_views/routines.cc remains unchanged. Since Stored Procedures and Functions can also utilize the VECTOR type for arguments and return values, this creates an inconsistency within INFORMATION_SCHEMA. Metadata sync tools will receive sanitized types from COLUMNS but raw strings (e.g., vector(128) or /*!80400 VECTOR */) from PARAMETERS or ROUTINES.

Questions:

1. Do you plan to unify the DATA_TYPE parsing logic across PARAMETERS.cc and ROUTINES.cc to ensure metadata consistency?
2. Regarding the I_S_VERSION, if we only fix the MTR checksum without bumping the version number, will it cause issues during in-place upgrades? Specifically, will the Data Dictionary successfully refresh the persisted system view definitions if the version remains the same?

I have locally verified that applying the same logic to all three files and bumping the I_S_VERSION fixes both the inconsistency and the MTR failure. I would like to confirm if this is the intended direction for AliSQL.

Best regards.

[p1p1bear]

@UsedByFeiYang
Thanks for the report. OK, we’ll take a look at this issue.

@JoeJRW could you please help investigate it?

[JoeJRW]

@UsedByFeiYang Thanks for the report and for providing a potential fix.

I’ve reviewed it, and the bug description is accurate. The proposed fix also looks reasonable.

Thanks again for taking the time to investigate and share this.