morningman opened a new pull request, #70482: URL: https://github.com/apache/doris/pull/70482
### Background A CHAR column keeps its length in `ScalarType`. A CHAR without a length, such as a view column defined as `CAST(x AS CHAR)`, and a CHAR(255) are both the "wildcard" CHAR (`ScalarType.isWildcardChar()`: length -1 or 255). Metadata statements print a column type through two `ScalarType` methods: `SHOW [FULL] COLUMNS` uses `toString()`, and `DESC`, `SHOW CREATE TABLE`, and the casts in EXPLAIN use `toSql()`. `information_schema.columns.COLUMN_TYPE` is built by the BE from the column length and prints `char(N)` for every CHAR. ### What problem does this PR solve? Issue Number: None Related PR: #24041 (introduced the `CHARACTER` spelling of the wildcard CHAR), #23580 (made CHAR(255) a wildcard CHAR), #37340 (added `(255)` to the spelling) PR Type: Bugfix Problem Summary: `SHOW [FULL] COLUMNS`, `DESC`, and `SHOW CREATE TABLE` print every CHAR(255) column, and every CHAR without a length, as `character(255)`, while `information_schema.columns` prints `char(255)` for the same column. Clients that map type names lose these columns: the OpenMetadata Doris connector does not recognize `CHARACTER` and drops them, CHAR columns of JDBC, Trino-connector, and MaxCompute catalogs included. These statements now print `char(255)`, the way VARCHAR prints `varchar(65533)`; printed DDL keeps its meaning, because the parser reads `CHARACTER` as `CHAR`. Most of the diff is tests and the expected outputs that recorded the old spelling. ### Details - **Frequency:** Always: `SHOW FULL COLUMNS` on any CHAR(255) column, or on a view column defined as `CAST(x AS CHAR)`, prints `character(255)`. - **Root cause:** `ScalarType.toString()` and `toSql()` print the wildcard CHAR as `character(255)`. #23580 made `isWildcardChar()` match length 255 too, #24041 then spelled the wildcard `CHARACTER` to replace the unparseable `CHAR(*)`, and #37340 appended `(255)`. The lexer reads `CHAR` and `CHARACTER` as one token, so the spelling means nothing to Doris, but clients that map type names don't know it. - **Why existing tests missed it:** Unit tests: none renders a CHAR(255) or a CHAR without a length (`TypeTest`, `ColumnTest`), and `DataTypeTest` only parses `character`. Regression suites: `test_show_columns_command` has no CHAR column and `test_string_basic` (from #24041) only queries a view built with `CAST(... AS CHARACTER)`, while `test_create_table_like_nereids` (from #37340) and the `.out` files of ten suites recorded `character(255)` as expected. None compared these statements with `information_schema.columns`. This PR updates all of them. - **Fix:** Print the wildcard CHAR as `char(255)` in both methods. Fixing only `SHOW COLUMNS` would leave `DESC ALL` printing both spellings in one row. `isWildcardChar()` and type matching are unchanged. - **Other paths and branches:** `information_schema.columns` and Nereids' `CharType.toSql()` already print `char`. `JdbcMySQLConnectorClient` accepts both spellings, so a Doris JDBC catalog keeps working against a Doris on either side of the upgrade. A sync MV created after the upgrade gets `char(255)` in a column name where an older MV has `character(255)`; query rewrite re-plans each MV from its original SQL and maps its columns by position (`MaterializationContext.tryGenerateScanPlan`), so existing MVs keep matching. `branch-3.1`, `branch-4.0`, `branch-4.1`, and `branch-4.2` have the same code, under `fe/fe-common`. - **Behavior change:** `character(255)` becomes `char(255)` in `SHOW [FULL] COLUMNS`, `DESC`, `SHOW CREATE TABLE`, EXPLAIN casts, the REST meta-info API, and error messages that name the type. Persisted metadata does not change. ### Testing All runs were local, on this branch's code: an FE built from master of 2026-11-07 with this PR's `ScalarType` compiled in (the file is identical in both), and a BE built from 6991e766329. - New suite `datatype_p0/string/test_wildcard_char_type_name` fails without the fix (`Expect cell is: array<char(255)> But real is: array<character(255)>`) and passes with it. - `test_create_table_like_nereids`, now expecting `` `name` char(255) ``, fails without the fix and passes with it; `test_string_basic` passes. - `schema_change_modify_mv_column_type` and `test_doris_all_types_select`: `.out` regenerated, keeping only the blocks whose type names changed; both pass. - Not run: the `.out` files of eight suites that need Trino-connector, GBase, DB2, or MaxCompute environments, updated by replacing `character(255)` with `char(255)` (17 places, all `DESC` or `SHOW CREATE TABLE` output). The External pipeline runs the Trino-connector ones. - FE UT `TypeTest#testWildcardCharPrintsAsChar`: the class's 21 tests pass. - The OpenMetadata Doris connector dropped `c_char_255`, `c_arr_char_255`, and `c_cast_char` without the fix, and ingests them as `CHAR(255)` with it. ### Notes for Reviewers In `schema_change_modify_mv_column_type.out`, the sync MV column `c4` over the `char(15)` column `c_char` was already a wildcard CHAR (printed `character(255)`) before this PR; only its printed name changes. ### Release note `SHOW [FULL] COLUMNS`, `DESC`, and `SHOW CREATE TABLE` print CHAR(255) columns and CHAR columns without a length as `char(255)` instead of `character(255)`, matching `information_schema.columns`. ### Check List (For Author) - Behavior changed: Yes (see Details) - Does this need documentation: No - Pre-submission status: Partially verified: the eight `.out` files of the external-environment suites (Trino connector, GBase, DB2, MaxCompute) were updated textually and not run locally ### AI Disclosure - Tool: Claude Code (Claude Opus 5.5) - Generated: code, tests, expected-output updates, this description - Human review: not stated - Prompts: Asked to fix Doris printing `character(255)` as part of the OpenMetadata integration work; chose to change both `toString()` and `toSql()` rather than only the `SHOW COLUMNS` output, to update the expected outputs of suites that need unavailable environments textually, and to verify on a local cluster with the recompiled class plus the FE unit test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
