Обсуждение: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."
parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."
От
Marius Andreiana
Дата:
Hello Postgres folks,
After reading
and the discussions at https://news.ycombinator.com/item?id=21150606
I'd also like to write "FROM... SELECT..." instead of "SELECT... FROM...".
Postgres doesn't support this though. Would it be possible to please add parsing support for this syntax as well?
Somebody mentioned:
Engines don’t run sql directly. They make an AST, make an intermediate representation of instructions and then execute.
So if it results in same AST, the parser should be flexible.
So if it results in same AST, the parser should be flexible.
Thanks!
Marius
Re: parser that could handle "FROM... SELECT..." as well as"SELECT... FROM..."
От
Pavel Stehule
Дата:
Hi
út 8. 10. 2019 v 8:12 odesílatel Marius Andreiana <marius.andreiana@gmail.com> napsal:
Hello Postgres folks,After readingand the discussions at https://news.ycombinator.com/item?id=21150606I'd also like to write "FROM... SELECT..." instead of "SELECT... FROM...".
This article is little bit strange, it mix syntax and execution together
Postgres doesn't support this though. Would it be possible to please add parsing support for this syntax as well?
PostgreSQL supports ANSI/SQL. ANSI/SQL doesn't allow use clauses in any order.
Personally I don't see any benefit of proposed feature - It breaks portability of SQL queries (that is not high today).
Regards
Pavel
Somebody mentioned:Engines don’t run sql directly. They make an AST, make an intermediate representation of instructions and then execute.
So if it results in same AST, the parser should be flexible.
Thanks!Marius
Re: parser that could handle "FROM... SELECT..." as well as"SELECT... FROM..."
От
Marius Andreiana
Дата:
Hi Pavel,
Personally I don't see any benefit of proposed feature - It breaks portability of SQL queries (that is not high today).
It would be up to each developer which form to use. Some use only PostgreSQL and don't need portability.
Also, more DBs could parse the new format as well in the future, so this issue will go away. Need to start somewhere.
Re: parser that could handle "FROM... SELECT..." as well as"SELECT... FROM..."
От
Pavel Stehule
Дата:
út 8. 10. 2019 v 9:14 odesílatel Marius Andreiana <marius.andreiana@gmail.com> napsal:
Hi Pavel,Personally I don't see any benefit of proposed feature - It breaks portability of SQL queries (that is not high today).It would be up to each developer which form to use. Some use only PostgreSQL and don't need portability.Also, more DBs could parse the new format as well in the future, so this issue will go away. Need to start somewhere.
I cannot to accept this argument. Lot of developers miss global perspective, and expect what is supported by one database, then all others supports too. Lot of code is created by mistake, and if parser will be tolerant, then this mistake will not be fixed.
I don't like a idea, so Postgres is first database that breaks ANSI/SQL. If ANSI/SQL changes syntax, I'll be for it.
More, I think so current strict mode is better for readability - every body knows, where can expect some, it is easy and simple. Don't see any reason to change it.
Pavel Stehule <pavel.stehule@gmail.com> writes: > út 8. 10. 2019 v 8:12 odesílatel Marius Andreiana < > marius.andreiana@gmail.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