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 (select 1 as a, 2 as b);
D insert into t1 values (1, 2);
D select from 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;