| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andreas Karlsson <andreas(at)proxel(dot)se> |
| Subject: | Re: FROM clause before SELECT |
| Date: | 2026-07-28 13:15:30 |
| Message-ID: | 9B4457AA-6BFD-45F5-9F24-88AA9A607EDE@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Vik,
Thank you! Here's v2: it is no longer "move FROM to the front", it
is "throw SELECT to the end".
On 27/07/2026 21:00, Vik Fearing wrote:
> This is a lot more serious, and if we are going to move the SELECT
> clause, I agree with Andreas K. that it belongs after HAVING or
> possibly even later.
This turned out to be simpler. To hack and to understand.
FROM films WHERE len > '02:00' GROUP BY kind SELECT kind, count(*)
WHERE, GROUP BY, HAVING and WINDOW keep their order relative to each
other and all come before the select list. ORDER BY, LIMIT and the
locking clauses stay at the end of the query, where they already are.
The SELECT clause may still be left out entirely, in which case it
means SELECT *, so "FROM films" works as before. So does the example I
started with: "FROM pg_stat_activity SELECT *".
Why not SELECT in the middle?
-----------------------------
v1 allowed the select list right after FROM, with the other clauses
trailing it. Accepting that placement along with "FROM in the end" is
doable. It costs a struct, a merge function and an error for a clause
written on both sides, just some grammar code.
What stopped me is not the grammar, but a way to convey the new feature.
We are adding a new way to write queries, and it has to be teachable.
"The select list can come last" is easy to understand. "The select list
may come first, second or last" is not a rule, it is a list of permissions
and I would not enjoy explaining it.
The argument on the other side is compatibility, and it is not weak.
DuckDB [0] and ClickHouse [1] both ship v1 placement, so a
query brought from either of them,
FROM films SELECT title WHERE len > '02:00'
works there and fails here. Nobody, as far as I know, ships the
placement in v2-patch grammar.
WDYT?
> The standard is never going to move the SELECT, so we are free to do
> so as an extension to the standard.
This sentence deserves a place in the commit message.
Thank you!
Best regards, Andrey Borodin.
[0] https://duckdb.org/docs/stable/sql/query_syntax/from
[1] https://clickhouse.com/docs/reference/statements/select/from
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Allow-a-query-to-be-written-with-its-select-list-.patch | application/octet-stream | 24.4 KB |
| unknown_filename | text/plain | 2 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2026-07-28 13:18:31 | Re: PSQL schema "describe" \dn is not escaping quotes |
| Previous Message | Daniel Gustafsson | 2026-07-28 13:13:54 | Re: datachecksums: handle invalid and dropped databases during enable |