Unparser emits empty SELECT list for empty Projection nodes, ignoring supports_empty_select_list

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

Mantenedores costumam responder em até 1 dia

@dreverri já está trabalhando nisso.

Desde 11/11/2026.

  • #27333 de @dreverri — aberto

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
20/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Estagnada
Stack de tecnologia
rust
Domínio
backend-api-design, databases

Direção de pesquisa

Read datafusion/sql/src/unparser/plan.rs, focusing on reconstruct_select_statement and empty_projection_fallback; the issue identifies the missing fallback for empty Projection expressions. Compare the generated SQL for a filtered count(*) query under the default and PostgreSQL dialects, and inspect the related tests. Done means unsupported empty select lists emit SELECT 1, while PostgreSQL retains SELECT FROM; a linked pull request is already open.

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

Descrição

Describe the bug

Unparsing the optimized plan of a simple count(*) query with a filter produces SELECT FROM ... (an empty select list), even for dialects whose supports_empty_select_list() is false. Engines that don't accept an empty select list reject the generated SQL. For example, BigQuery fails with:

SELECT list must not be empty

The column used in the filter isn't needed above the Filter, so optimize_projections prunes it and leaves a Projection with no expressions:

Projection: count(Int64(1)) AS count(*)
  Aggregate: groupBy=[[]], aggr=[[count(Int64(1))]]
    Projection:
      Filter: t.id > Int32(10)
        TableScan: t projection=[id]

#19221 (closing #18991) added Dialect::supports_empty_select_list and a SELECT 1 fallback, but only the TableScan path checks it (the case where the scan has projection=[], as in select count(*) from t with no filter). An empty Projection node goes through reconstruct_select_statement, which uses p.expr as is.

To Reproduce
use datafusion::prelude::SessionContext;
use datafusion::sql::unparser::plan_to_sql;

let ctx = SessionContext::new();
ctx.sql("create table t (id int)").await?.collect().await?;
let plan = ctx
    .sql("select count(*) from t where id > 10")
    .await?
    .into_optimized_plan()?;
println!("{}", plan_to_sql(&plan)?);

Output (default dialect):

SELECT count(1) AS "count(*)" FROM (SELECT FROM t WHERE (t.id > 10))

BigQueryDialect produces the same thing with backtick quoting.

Expected behavior

An empty Projection should get the same dialect-dependent fallback as an empty TableScan projection:

  • Dialects with supports_empty_select_list() == false (default, BigQuery, ...): 
    SELECT count(1) AS "count(*)" FROM (SELECT 1 FROM t WHERE (t.id > 10))
  • Dialects that support it (PostgreSQL): unchanged, SELECT FROM ...
Additional context

The fix is small: in reconstruct_select_statement (datafusion/sql/src/unparser/plan.rs), use self.empty_projection_fallback() when p.expr is empty. I'll open a PR with the fix and tests.

Linguagem predominante
Rust
Estrelas
9.6k
Forks
2.6k
Merge médio
3d 4h
PRs com merge (30d)
345

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

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 apache/datafusion

Todas as issues de apache/datafusion

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

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