parseColumnType throws on named Tuple types (Tuple(name Type, ...))

[polyglotAI-bot]

Summary

parseColumnType (exported @experimental from @clickhouse/client / @clickhouse/client-web, and re-exported from @clickhouse/client-common) throws ColumnTypeParseError: Unsupported column type when given a named Tuple type such as Tuple(s String, i Int64) — the exact shape ClickHouse returns from DESCRIBE TABLE (and in the RowBinaryWithNamesAndTypes / Native headers) for a column declared as a named tuple. Unnamed tuples (Tuple(String, Int64)) parse fine.

Reproduction

import { parseColumnType } from "@clickhouse/client"; // or client-web / client-common
parseColumnType("Tuple(s String, i Int64)");
// throws: ColumnTypeParseError: Unsupported column type  { columnType: "s String" }

Root cause

parseTupleType strips the Tuple( … ) wrapper and uses getElementsTypes to split the body on top-level commas, then passes each element verbatim to parseColumnType. For a named tuple the elements are "s String" / "i Int64" (name + space + type); "s String" matches no known type prefix and is not in SimpleColumnTypes, so it hits the else branch in parseColumnType (packages/client-common/src/parse/column_types.ts:217) and throws. There is no logic to strip the optional element-name prefix before recursing.

Expected

parseColumnType("Tuple(s String, i Int64)") should return a ParsedColumnTuple with elements String and Int64 (and, ideally, the element names preserved).

Notes

• Realistic trigger: inspect column types via DESCRIBE TABLE, then feed them back into the parser.
• Mirrors the upstream Java bug ClickHouseColumn bug when parsing a tuple type clickhouse-java#889 (ClickHouseColumn.parse("col Tuple(s String, i Int64)") → Unknown data type: s String).
• Server version is not load-bearing (purely client-side string parsing).