From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Marius Andreiana <marius(dot)andreiana(at)gmail(dot)com>, pgsql-sql(at)lists(dot)postgresql(dot)org |
Subject: | Re: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..." |
Date: | 2019-10-08 14:29:30 |
Message-ID: | 19446.1570544970@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> út 8. 10. 2019 v 8:12 odesílatel Marius Andreiana <
> marius(dot)andreiana(at)gmail(dot)com> napsal:
>> After reading
>> https://jvns.ca/blog/2019/10/03/sql-queries-don-t-start-with-select/
>> and the discussions at https://news.ycombinator.com/item?id=21150606
>> I'd also like to write "FROM... SELECT..." instead of "SELECT... FROM...".
> Personally I don't see any benefit of proposed feature - It breaks
> portability of SQL queries (that is not high today).
The one advantage I could see to this is that, in principle,
it would allow tab-completion in the SELECT list to know
what column names to offer. Of course, making that actually
work would take a huge amount of effort, since psql's tab
completion "parser" is so lame.
On balance I agree that's not attractive enough to justify the
compatibility gotchas we'd be introducing. Postgres does have
some intentional deviations from the SQL standard, but they
seem to me to have better justifications than this one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Martin | 2019-10-08 15:48:40 | Qusetion re regexexp_split_to_array and last occurence |
Previous Message | Pavel Stehule | 2019-10-08 07:25:21 | Re: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..." |