geoffreyclaude opened a new issue, #24754:
URL: https://github.com/apache/datafusion/issues/24754

   ## Describe the bug
   
   `RelationPlanner` extensions get the first chance to handle a `TableFactor`. 
If every extension returns `RelationPlanning::Original`, DataFusion's default 
relation planner currently accepts several table modifiers but silently drops 
them.
   
   For example, a query such as:
   
   ```sql
   SELECT * FROM my_table TABLESAMPLE SYSTEM (10 PERCENT)
   ```
   
   can become an ordinary full table scan. The query succeeds, but it no longer 
means what the user wrote. The same fall-through pattern exists for version 
qualifiers, table hints, partition selection, JSON paths, index hints, `WITH 
ORDINALITY`, and table-function `SETTINGS`.
   
   This matters more now that relation planners are being used in real projects 
to implement exactly this kind of syntax:
   
   - [Paimon handles `VERSION AS OF` and `TIMESTAMP AS 
OF`](https://github.com/apache/paimon-rust/blob/8001f02d8cc33bd3d5d77a1e7de781ff3add28d6/crates/integrations/datafusion/src/relation_planner.rs#L86-L104).
   - [VGI handles 
`TABLESAMPLE`](https://github.com/Query-farm/vgi-datafusion/blob/c6e3a6cfb05202a61233aa535912d8e2faae3e6e/src/sampling.rs#L65-L76).
   - [Coral explicitly rejects every modifier it does not 
consume](https://github.com/withcoral/coral/blob/8678de77aba0faed532e9b43995702a835dacca4/crates/coral-engine/src/runtime/scoped_table_functions.rs#L180-L223),
 including exhaustive field matching so a future sqlparser field cannot be 
ignored by accident.
   
   ## To reproduce
   
   Register a normal table and plan the `TABLESAMPLE` query above without a 
relation extension that claims it (or with a pass-through extension). The 
resulting plan is an unsampled table scan.
   
   ## Expected behavior
   
   Extensions should remain free to implement these modifiers. If none does, 
the default planner should fail closed with a clear “not supported” error 
rather than execute different semantics.
   
   The default planner should also destructure relevant `TableFactor` variants 
exhaustively. That makes a future sqlparser modifier a compile-time decision 
instead of another possible silent omission.
   
   ## Additional context
   
   This is a planning-time correctness guard. Queries without these modifiers 
keep the same planning path.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to