zclllyybb commented on issue #3883:
URL: https://github.com/apache/doris-website/issues/3883#issuecomment-4601461355
Breakwater-GitHub-Analysis-Slot: slot_fdfc1ed06e14
Initial analysis from current Apache Doris upstream/master (`80158100b32`,
fetched 2026-06-02):
This looks like expected display and metadata compatibility behavior, not a
corruption or loss of the column's real Doris type.
Evidence from the current code path:
- DDL parsing treats `STRING` and `TEXT` as the same Doris string type. In
the Nereids parser type conversion, both `text` and `string` become
`StringType.INSTANCE`, and `StringType.toCatalogDataType()` returns
`Type.STRING`. The legacy catalog type factory also maps both `STRING` and
`TEXT` to `ScalarType.createStringType()`.
- `SHOW CREATE TABLE` prints the stored type through `Column.toSql(...)` and
`ScalarType.toSql()`. For `PrimitiveType.STRING`, that renderer currently
outputs `text`.
- `DESC` / unfiltered `SHOW COLUMNS` uses the catalog type display path too,
so `STRING` is also displayed as `text` there.
- `information_schema.columns` is populated by the BE schema columns
scanner. Its `DATA_TYPE` column is explicitly converted for MySQL
compatibility, and maps both `VARCHAR` and `STRING` to `varchar`. In the same
scanner, the Doris-specific `COLUMN_TYPE` value for `STRING` is `string`.
So the expected behavior on current master is:
- `CREATE TABLE ... (c STRING ...)` and `CREATE TABLE ... (c TEXT ...)`
define the same Doris `STRING` column type.
- `SHOW CREATE TABLE` and `DESC` may display this type as `text`.
- `information_schema.columns.DATA_TYPE` may display `varchar` for
compatibility.
- `information_schema.columns.COLUMN_TYPE` should display `string` for this
Doris type.
The website issue is therefore a valid documentation gap. A useful doc note
would be to explain that `STRING` and `TEXT` are accepted aliases for the same
Doris variable-length string type, `SHOW CREATE TABLE` / `DESC` may
canonicalize it as `TEXT`, and `information_schema.columns.DATA_TYPE` follows
MySQL-compatible metadata while `COLUMN_TYPE` is the better field for checking
the Doris-specific column type.
Missing information only if maintainers want to check a version-specific
inconsistency:
- Doris version/build.
- Minimal `CREATE TABLE` statement.
- Exact selected metadata output, especially:
`select column_name, data_type, column_type from
information_schema.columns where table_name = '...';`
- If `COLUMN_TYPE` also returns `varchar` for a `STRING`/`TEXT` column, that
would not match the current master code path and should be investigated as
version-specific behavior or a bug.
--
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]
