3 ms·
An SQL parser has no problem supporting both forms as there is no parsing ambiguity. (SQL is full of corner cases e.g. EXTRACT(WEEKDAY FROM field) etc. Puttin
by willvarfar 3y ago
An SQL parser has no problem supporting both forms as there is no parsing ambiguity.
(SQL is full of corner cases e.g. EXTRACT(WEEKDAY FROM field) etc. Putting the FROM first, or supporting multiple chained WHERE clauses or allowing WHERE before JOIN and applying to the preceding projection etc is all possible in an SQL parser that chooses to allow some relaxations. Personally, I am really irritated that I can't have HAVING without GROUP or QUALIFY without window functions etc, as I often construct queries programmatically.)
- deepsun 3y agoNitpick -- SQL was not designed to be used programmatically. Same as shell commands, it's for humans to write manually. Proper API could have way more concise, and much more efficient format to parse. And would avoid a bunch of security issues along the way, same as for shell.
- rangerelf 3y agoExactly. I still remember about this "revolutionary" querying language being designed, that would allow for non-technical people to perform complex queries and reports from databases. People: stop trying to mangle SQL "because it would be better..."; nah, SQL is supposed to be the "better" already. The idiosyncrasies it has is because it was designed to be kinda-sorta conversational, modeled as an english language query.
- randomdata 3y ago> SQL is supposed to be the "better" already. For non-technical people. It is not supposed to be the "better" for the technical people who end up using SQL in practice. QUEL was the "better" for us, being much closer to Codd's vision. But, alas, Oracle won with the business people and Postgres lost.
- The_Colonel 3y agoThis specific issue is a problem for humans, not for APIs. I have a very smart SQL IDE with great intellisense, but when I type "SELECT", it can't help me because it has no idea what I want. Being able to type "FROM table SELECT" would be way friendlier for humans, because IDEs could offer me immediately columns I'm very likely interested in.
- deepsun 3y agoI usually write "SELECT FROM a" and then "Ctrl-Left-Left" to go back to columns. Starting from FROM would be better of course.
- randomdata 3y agoWhy is a very smart SQL IDE not able to work around that limitation with smart UI/UX? I can see why baby's first SQL IDE would benefit from the language being amenable to IDEs, but a very smart one should be able to take things further, no?
- mrguyorama 3y agoAlright, I start typing out "SELECT" in my super smart IDE, how does it know which table to suggest columns from?
- randomdata 3y agoGiven that it is a very smart IDE, the column suggestion UI integrates table selection in a smart way. Once the IDE knows which table(s) you are referencing, it automatically fills in the FROM clause for you.
- The_Colonel 3y agoLooks like my IDE isn't that smart. So I will have to endure the unfriendliness of the SQL towards humans.
- 3y ago