4 ms·

Regarding table literals, some products support using VALUES (1, 'a'), (2, 'b'), ... as a table constructor in general, not just in INSERT, and looking at S

by saarni 6y ago

Regarding table literals, some products support using VALUES (1, 'a'), (2, 'b'), ... as a table constructor in general, not just in INSERT, and looking at SQL:92, SQL:99, and SQL:2003 it looks to me like this should be standard SQL. Derived tables, aka subqueries, exist in SQL:92 at least as well, so whether or not that is considered recent depends on how you look at it, I think. I am not trying to defend SQL with this, and all in all this does not take away from the points you raised, but the above were something that stood out.

Joker_vD 6y ago
They were in SQL:92, but IIRC adoption was somewhat slow and patchy, and has generally finished somewhen in the early 2000s. My point is, the parent's claim that SQL "operate[s] on sets of data (aka tables) using set theory", and does it "really well" but when you actually look at SQL, you realise that sets/tables aren't really first-class ― derived tables were added in later versions of SQL, and literal tables still don't exist, but those are things you expect a language focused on table manipulations to have. Nope, it's a language for building very specific kinds of queries which was then patched and extended into something more general.
- deleted 6y ago
  [deleted]