ClickHouse / ClickHouse/clickhouse-js

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

Open Beginner friendly
#891 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
331
Forks
74
PR merge metrics
No merged PRs in 30d

Description

## 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

```ts
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 https://github.com/ClickHouse/clickhouse-java/issues/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).

Contributor guide

Open the contributing guide

Research direction

Start with parseColumnType and parseTupleType in packages/client-common/src/parse/column_types.ts, especially the else branch at line 217 and the getElementsTypes call. Reproduce the named-tuple failure, then verify that parsing Tuple(s String, i Int64) yields String and Int64 elements, with names preserved if supported.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
databases
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.