Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Unknown type names inside a container are misread instead of rejected

Aberta
  • Algo errado?
#589 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Hakaou já está trabalhando nisso.

Desde 18/10/2026.

  • #590 de @Hakaou — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
clickhouse, cpp
Domínio
backend, databases

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
C
Estrelas
386
Forks
212
Merge médio
18h 22min
PRs com merge (30d)
4

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ClickHouse/clickhouse-cpp

Todas as issues de ClickHouse/clickhouse-cpp

Issues semelhantes

Mais issues de C

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.