parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."

Marius Andreiana-2
Hello Postgres folks,

After reading
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. 

Thanks!
Marius
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> napsal:
Hello Postgres folks,

After reading
I'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
Reply | Threaded
Open this post in threaded view
|

Re: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."

Marius Andreiana-2
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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

Re: parser that could handle "FROM... SELECT..." as well as "SELECT... FROM..."

Tom Lane-2
In reply to this post by Pavel Stehule
Pavel Stehule <[hidden email]> writes:
> út 8. 10. 2019 v 8:12 odesílatel Marius Andreiana <
> [hidden email]> 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