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

Ouverte
  • Quelque chose ne va pas ?
#27,332 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@dreverri y travaille déjà.

Depuis le 11/11/2026.

  • #27333 par @dreverri — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
20/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
rust
Domaine
backend-api-design, databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
9.6k
Forks
2.6k
Merge moyen
3 j 4 h
PR mergées (30 j)
345

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/datafusion

Toutes les issues de apache/datafusion

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.