Hacker News Reader

Comment by willvarfar | Hacker News Reader

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.)

View on HN

Nitpick -- 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.

Exactly. 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.

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

This 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.

Why 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?

Alright, I start typing out "SELECT" in my super smart IDE, how does it know which table to suggest columns from?

Given 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.

Looks like my IDE isn't that smart. So I will have to endure the unfriendliness of the SQL towards humans.

Or just use a better language. SQL was designed for non-technical people, using statements that resemble the English they already know. It was not designed for tech-minded people who are able to grasp higher level technical concepts.

I usually write "SELECT FROM a" and then "Ctrl-Left-Left" to go back to columns. Starting from FROM would be better of course.

Reply on news.ycombinator.com