81–90 of 137 posts
FROM is not a command, it's a parameter, and an optional one at that. This is valid SQL. SELECT 1; The SQL commands are SELECT, UPDATE, INSERT, etc. Therefore, those commands should be the first thing in an instruction. If you have a file full of SQL, you probably want all the lines to start with those commands. Gonna be pretty weird to read if you have both SELECT and UPDATE lines that start with FROM. Probably diff…
FROM ℝ SELECT 1
Azure query language's Kusto, lously based on a mix of F# and SQL, does it, as does LINQ. I end up always starting with the generic form select * from db, and then go from there, as code completion then works if there is at least one db.
You're probably getting downvoted just because of Azure, but you are right. ADX/Kusto and KQL is an extremely powerful query language that answers exactly what OP questions about SQL. Here's an example of a KQL query that I have in my browser... Things | where DeviceTags has "Installed" | order by LastHeardFromTimeStamp desc | take 10 KQL also takes ideas from R's Tidyverse and magrittr package. It takes datasets and…
Earlier quoted context omitted.
> This is valid SQL. > SELECT 1; Something like Oracle's "dual" table would handle this corner case. Or just selecting a value from itself: FROM 1 SELECT 1; or FROM ::integer SELECT 1; Or whathaveyou. In any case, the SELECT 1 case isn't fatal to putting FROM first, merely annoying. > Intelligent tooling can and does already solve this. It can progressively guess as you type, but it can't provide an upfront list of a…
Given how often `SELECT ` is already the developer "default" especially in debugging and REPL work there's a good case that `SELECT ` can truly just be the implied default case and something like `FROM 1` makes perfect sense as a standalone statement.
DuckDB has an implicit "SELECT *" if you just give it "FROM tablename", which fits your example.
RANGE OF t IS table
RETRIEVE INTO target (t.column1, t.column2)
WHERE t.condition
SELECT t.column1, t.column2
FROM table t
WHERE t.condition
RANGE OF t1 IS table1
RANGE OF t2 IS table2
RETRIEVE INTO target (t1.column, t2.column) WHERE t1.common = t2.commonEarlier quoted context omitted.
that may very well be the case but perhaps there could be an evolution of the language because for newcomers the idea that the from clause is evaluated/executed/defined first is a pain point. Newbies I help sometimes wonder why things they reference in the SELECT part aren't visible/available in the FROM clause and that's because one is selecting the result of FROM ... JOIN ... WHERE etc anyway
> he idea that the from clause is evaluated/executed/defined first is a pain point Maybe my brain is broken by years of SQL and from learning English as a second language. But isn’t this supposed to follow a fairly mundane English sentence structure? “Select socks and pants from drawer”. If you started saying “from drawer select socks and pants”, wouldn’t that feel like a weird sentence structure to most people?
But generally SQL is often very nicely translatable to English at least for me and so long as the SQL isn’t too overly complex.
I still largely reject the code completion complaint. Specifically, it is very common to know what columns you want before you know what tables have said columns. This is especially true on normalized schemas where you are almost certainly having to do some joins to get all that you want. So, does it somewhat complicate the logic? Of course. It is by no means impossible, though, and unless you are using super generic…
FROM is not a command, it's a parameter, and an optional one at that. This is valid SQL. SELECT 1; The SQL commands are SELECT, UPDATE, INSERT, etc. Therefore, those commands should be the first thing in an instruction. If you have a file full of SQL, you probably want all the lines to start with those commands. Gonna be pretty weird to read if you have both SELECT and UPDATE lines that start with FROM. Probably diff…
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…
Linq does this [0], maybe partially because it's SQL-like but built for working with enumerables instead so they could do what they wanted. One other quirk of SQL ordering that always gets me is that SET comes before WHERE in UPDATE. I always get terrified that I'll run without the WHERE or without selecting the WHERE. Thankfully a good database tool like DataGrip will yell at you if you try to do a modifying operati…
However if you write FROM table SELECT x, the IDE can first provide intellisense for table names while you write your FROM clause. Then it can provide intellisense for the SELECT clause based on columns in the tables/views/etc you listed in your FROM. So it was basically done for better UX.
SQL is a mess. It's actually a fairly well-thought-out and straightforwards language. However, in the quest to make it 'human-readable', it's very unintuitive to compose.
FROM is not a command, it's a parameter, and an optional one at that. This is valid SQL. SELECT 1; The SQL commands are SELECT, UPDATE, INSERT, etc. Therefore, those commands should be the first thing in an instruction. If you have a file full of SQL, you probably want all the lines to start with those commands. Gonna be pretty weird to read if you have both SELECT and UPDATE lines that start with FROM. Probably diff…