Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Unknown type names inside a container are misread instead of rejected

未关闭
  • 哪里不对？
#589 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@Hakaou 已经在做这个了。

开始于 2026年10月18日。

  • #590 来自 @Hakaou —— 未关闭

评估

难度
4/5
预计耗时
1-2 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
clickhouse, cpp
领域
backend, databases

调研方向

Read the parser and column factory paths discussed in the issue, especially CreateColumnByType and ValidateAST, then review #575 and the stacked draft #590 for the Nested node and container handling. Add validation so unknown types inside the six supported containers fail with the same unsupported column type error as root types, while preserving Nothing behavior. Verify with the reported Array(Int256) case and the existing container tests; the client should reject it instead of misreading the block.

由索引模型根据 Issue 内容生成。

描述

Follow-up to the second point of the suggested fix in #571, which #575 leaves aside: validating the elements of a container, so that an unknown type name fails loudly instead of desynchronising the stream.

A type name the parser does not know becomes a Void terminal. At the root, ValidateAST rejects it and the client throws "unsupported column type". Inside a container nothing checks it: the column is created as ColumnNothing, which reads one byte per row, and the rest of the block is misread, with no error naming the type.

In the client itself, on master (fc5d98f):

CreateColumnByType("Int256");         // nullptr, the client reports "unsupported column type: Int256"
CreateColumnByType("Array(Int256)");  // a column typed Array(Void), no error

Against ClickHouse 26.11:

SELECT CAST(1, 'Int256') AS wide     -- UnimplementedError: unsupported column type: Int256
SELECT [CAST(1, 'Int256')] AS wide   -- without compression: one row, no exception, wrong content. With LZ4: some data was not read

Other names a server sends as is and the parser does not know, checked with toTypeName on 26.11: Variant, Dynamic, BFloat16, UInt256, the Interval* types, LineString, MultiPoint, QBit, AggregateFunction. At the root each of them is an error. Inside an Array, what happens depends on the type and the compression: without compression Int256, UInt256, QBit, AggregateFunction and the Interval* types come back as wrong data with no exception, BFloat16, Variant, Dynamic, LineString and MultiPoint fail later with unrelated errors (unimplemented 63, unsupported custom serialization, unimplemented 8176), and with LZ4 every one of them fails with some data was not read. None of these errors names the type. Nothing goes through the same path and only works by accident, one byte per row on both sides, which SELECT [] and SELECT NULL rely on.

#578 handles the neighbouring case, a type the parser accepts but the factory cannot build inside a wrapper, which crashed. This one is about names the parser does not know at all, and the two change different functions.

#590 is a draft for it, stacked on #575 because it needs the Nested node from there. It validates the elements of those six containers, leaves the arguments of every other type alone (JSON settings and typed paths, the function name of SimpleAggregateFunction), and registers Nothing. An unknown name inside a container then makes CreateColumnByType return nullptr, so the client throws the same "unsupported column type" as at the root.

Would you rather have a diagnostic that names the inner type? The draft's tests would then expect it instead of nullptr.

主要语言
C
星标
386
派生
212
平均合并
18 小时 22 分钟
30 天内合并 PR
4

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ClickHouse/clickhouse-cpp 的其他 Issue

查看 ClickHouse/clickhouse-cpp 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。