lhadhazy commented on issue #17349:
URL: https://github.com/apache/datafusion/issues/17349#issuecomment-5634330116

   This does not reproduce on `main` any more, and I think it can be closed.
   
   Checked on `6263df2ca` (DataFusion CLI v55.0.0), using `generate_series` so 
that no custom table function is needed:
   
   ```sql
   -- baseline
   > SELECT * FROM generate_series(1, 3);
   +-------+
   | value |
   +-------+
   | 1     |
   | 2     |
   | 3     |
   +-------+
   
   -- the shape reported here: a subquery as one argument among several
   > SELECT * FROM generate_series((SELECT 1), 3);
   Error during planning: Arguments must be literals
   
   -- a subquery as the only argument
   > SELECT * FROM generate_series((SELECT 3));
   Error during planning: Arguments must be literals
   ```
   
   The error rather than the absence of one is the point, so here is the 
control that separates the two cases — a call with no arguments at all reports 
something different:
   
   ```sql
   > SELECT * FROM generate_series();
   Error during planning: generate_series function requires 1 to 3 arguments
   ```
   
   Since the one-argument subquery call reports `Arguments must be literals` 
and not the argument-count error, the subquery is reaching `generate_series` 
rather than being dropped on the way. That is the second of the two outcomes in 
the original report — an error instead of a silently missing argument.
   
   The change appears to be commit `b09205afc`, *"fix: propagate errors for 
unsupported table function arguments instead of silently dropping them"* 
(`#21135`, merged 2026-03-28), which replaced the 
`.flat_map(...).collect::<Vec<_>>()` in `datafusion/sql/src/relation/mod.rs` 
with `.map(...).collect::<Result<Vec<_>>>()?`. `flat_map` over a `Result` 
yields no elements for an `Err`, which is the mechanism described in the 
comment above. That PR closed `#21125`, which reported the same defect through 
a different symptom, and did not reference this issue, which is probably why 
this one stayed open.
   
   One gap is left behind, if it is of interest. The sqllogictest cases that PR 
added to `table_functions.slt` cover named arguments and wildcards, both of 
which take the `else` branch of that `match`. A subquery argument takes the 
other branch, through `sql_expr_to_logical_expr` and `parse_scalar_subquery`, 
and has no test. I am happy to open a small PR adding one so the behaviour this 
issue describes cannot regress unnoticed — happy to skip it if you would rather 
not grow the file.
   


-- 
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