Support from-first SQL syntax

[simonvandel]

Which issue does this PR close?

• Closes #.

Rationale for this change

I noticed in #17278 that from without an explicit projection did not work.
This should fix it.

The from-first syntax is also available in duckdb. See https://duckdb.org/docs/stable/sql/query_syntax/from.html#examples

What changes are included in this PR?

Are these changes tested?

Yes, added SLT test

Are there any user-facing changes?

FROM-first syntax without projection is now supported.

[alamb]

🤯 -- thank you @simonvandel

I also verified duckdb does support this

D create table t(x int);
D insert into t values (1);
D from t;
┌───────┐
│ x │
│ int32 │
├───────┤
│ 1 │
└───────┘

@Jefffrey or @jonahgao -- any concern about supporting this syntax?

[Jefffrey]

I've used this in DuckDB before and agree it's pretty slick & handy;

Maybe need to update the SQL reference docs with this new behaviour?

• https://datafusion.apache.org/user-guide/sql/select.html

[simonvandel]

Maybe need to update the SQL reference docs with this new behaviour?

* https://datafusion.apache.org/user-guide/sql/select.html

I added some documentation in 9f1b436

[Jefffrey]

LGTM 👍

[alamb]

@xudong963 found this PR seems to have introduced a regression

• Regression: projection pushdown doesn't work as expected in DF50 #17513

@adriangb has a proposed PR up to fix:

• Revert #17295 (Support from-first SQL syntax) #17520

[adriangb]

@alamb we discussed a bit in #17520 (comment), I'm not sure that this PR introduced a bug. If I understand correctly select from t1 should be equivalent to select * from t1 -> then there is no bug. Now if select from t1 is meant to be select every row but no columns then there is a bug but it has nothing to do with the where clause or projection pushdown.

FWIW:

DataFusion CLI v50.0.0
> create table t1 (a int, b int);
0 row(s) fetched. Elapsed 0.004 seconds.
> insert into t1 values (1, 2);
+-------+
| count |
+-------+
| 1 |
+-------+
1 row(s) fetched. Elapsed 0.010 seconds.
> select * from t1;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+
1 row(s) fetched. Elapsed 0.003 seconds.
> select from t1;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+
1 row(s) fetched. Elapsed 0.004 seconds.
> from t1;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
+---+---+
1 row(s) fetched. Elapsed 0.001 seconds.

Postgres:

postgres=# create table t1 (a int, b int);
CREATE TABLE
postgres=# insert into t1 values (1), (2);
INSERT 0 2
postgres=# select * from t1;
a | b ---+---
1 | 2 | (2 rows)
postgres=# select from t1;
--
(2 rows)
postgres=# from t1;
ERROR: syntax error at or near "from"
LINE 1: from t1;

DuckDB:

DuckDB v1.3.2 (Ossivalis) 0b83e5d2f6
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
D create table t1 AS (select1as a, 2as b);
D insert into t1 values (1, 2);
D selectfrom t1;
Parser Error:
SELECT clause without selection list
D from t1;
┌───────┬───────┐
│ a │ b │
│ int32 │ int32 │
├───────┼───────┤
│ 1 │ 2 │
│ 1 │ 2 │
└───────┴───────┘

[adriangb]

So maybe the answer is that we should make select from t1; equivalent to "select no columns from t1" while keeping from t1; equivalent to select * from t1;?

[alamb]

So maybe the answer is that we should make select from t1; equivalent to "select no columns from t1" while keeping from t1; equivalent to select * from t1;?

I think we should be consistent with other databases

This proposal seems reasonable to me

SHould we also make from t (without anything else) an error like it is in duckdb?

[adriangb]

SHould we also make from t (without anything else) an error like it is in duckdb?

DuckDB does support FROM t;, it does not support SELECT FROM t;