关于string字段类型

[kuiyr0810]

当我创建表指定某个字段为string类型

使用show create table tablename;
查看会显示为text类型

使用desc tablename;
查看会显示为text类型

使用select * from information_schema.columns where table_name = 'tablename';
查看会显示为vachar

这是特性还是bug

能否在文档中添加解释

[zclllyybb]

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.