Re: FROM clause before SELECT

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

In response to

Browse pgsql-hackers by date

  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