Describe the bug
The official RelationPlanner TABLESAMPLE example recursively plans the underlying table with its alias still attached, then returns the same alias in PlannedRelation.
Those two APIs both apply aliases:
RelationPlannerContext::plan(...) applies the alias on the inner relation.- DataFusion applies
PlannedRelation::alias around the completed extension plan.
As a result, an alias with a column list is represented twice in the logical plan. Besides making the plan noisy, the duplicate projections make the example a risky pattern for downstream implementations to copy.
That has already happened in the wild: VGI's sampling planner follows the example's recursive-planning pattern and returns the alias again with the completed plan.
To reproduce
Run the example planner with an alias that renames columns:
SELECT *
FROM sample_data AS sampled(first, second)
TABLESAMPLE (3 ROWS)
The logical plan contains two SubqueryAlias: sampled nodes and two alias projections.
Expected behavior
The example should remove the outer alias before recursively planning the underlying table, then return that alias with the completed sampled plan. The logical plan should contain one relation alias and one column-renaming projection.
The public API docs and user guide should state this ownership rule clearly so extension authors know which layer applies the alias.
Additional context
This is an example and documentation repair; the core alias application behavior does not need to change.
Describe the bug
The official
RelationPlannerTABLESAMPLEexample recursively plans the underlying table with its alias still attached, then returns the same alias inPlannedRelation.Those two APIs both apply aliases:
RelationPlannerContext::plan(...)applies the alias on the inner relation.PlannedRelation::aliasaround the completed extension plan.As a result, an alias with a column list is represented twice in the logical plan. Besides making the plan noisy, the duplicate projections make the example a risky pattern for downstream implementations to copy.
That has already happened in the wild: VGI's sampling planner follows the example's recursive-planning pattern and returns the alias again with the completed plan.
To reproduce
Run the example planner with an alias that renames columns:
The logical plan contains two
SubqueryAlias: samplednodes and two alias projections.Expected behavior
The example should remove the outer alias before recursively planning the underlying table, then return that alias with the completed sampled plan. The logical plan should contain one relation alias and one column-renaming projection.
The public API docs and user guide should state this ownership rule clearly so extension authors know which layer applies the alias.
Additional context
This is an example and documentation repair; the core alias application behavior does not need to change.