3 ms·

>I mean, have any vendors actually gone beyond SQL-92? Yes. Here's a pretty good summary presentation (it says it's Postgres-focused, but it provides adoption

by greggyb 11y ago

>I mean, have any vendors actually gone beyond SQL-92? Yes. Here's a pretty good summary presentation (it says it's Postgres-focused, but it provides adoption data for the major vendors)[0] and the HN comments[1]. What we tend to see (I speak from a position as a BI consultant - I get to see lots of companies' database infrastructure) is that adoption of new SQL constructs is mostly limited by the developers, and in some cases IT departments who won't upgrade SQL server software. New SQL being limited by developers comes in two flavors, crusty DBAs and do-it-all-in-the-app-layer developers. The second type tends to be more common among demographics similar to HN. [0] http://www.slideshare.net/MarkusWinand/modern-sql http://www.slideshare.net/MarkusWinand/modern-sql [1] https://news.ycombinator.com/item?id=9018129 https://news.ycombinator.com/item?id=9018129

moron4hire 11y ago
That's a pretty abysmal report. You basically can't count on any of those features to be available across databases. You are correct about the fear-of-SQL amongst most application developers.
- greggyb 11y ago
  The target is moving. Your question: "Have any vendors moved beyond SQL-92?" The answer is a clear yes. The question was not, "Do all major RDBMSs support the same subset of the SQL standard?" The implied concern with the new question is portability of code across databases. This is a red herring based only on some snippets of SQL syntax and features.[0] Even if the SQL were identical, no major RDBMS has as its selling point that it only supports the SQL standard. Additionally, even with identical SQL, the implementations in each RDBMS are different enough that logically equivalent code would still need to be rewritten. One example: There is nothing in the SQL standard about optimization of queries. One place this shines through is in Postgres CTEs vs MS SQL Server CTEs (I cannot speak to other implementations). In Postgres, a CTE is an optimization boundary - predicates from the query utilizing a CTE will not be pushed down into the CTE. The entire CTE is executed each time it is referenced. This is in contrast to the behavior of sub-queries, which do support predicates being pushed down into them. In SQL Server, CTEs are just an in-line view definition and do support predicates being pushed into the CTE from the outer query. Any codebase converting from MS SQL Server to Postgres would need to have every instance of CTE use evaluated for performance. [0] The previously linked deck highlights only some advanced excerpts of the SQL standard. The venn diagram of supported SQL constructs is much more overlap than exclusive.

by greggyb 11y ago

moron4hire 11y ago

That's a pretty abysmal report. You basically can't count on any of those features to be available across databases. You are correct about the fear-of-SQL amongst most application developers.

greggyb 11y ago
The target is moving. Your question: "Have any vendors moved beyond SQL-92?" The answer is a clear yes. The question was not, "Do all major RDBMSs support the same subset of the SQL standard?" The implied concern with the new question is portability of code across databases. This is a red herring based only on some snippets of SQL syntax and features.[0] Even if the SQL were identical, no major RDBMS has as its selling point that it only supports the SQL standard. Additionally, even with identical SQL, the implementations in each RDBMS are different enough that logically equivalent code would still need to be rewritten. One example: There is nothing in the SQL standard about optimization of queries. One place this shines through is in Postgres CTEs vs MS SQL Server CTEs (I cannot speak to other implementations). In Postgres, a CTE is an optimization boundary - predicates from the query utilizing a CTE will not be pushed down into the CTE. The entire CTE is executed each time it is referenced. This is in contrast to the behavior of sub-queries, which do support predicates being pushed down into them. In SQL Server, CTEs are just an in-line view definition and do support predicates being pushed into the CTE from the outer query. Any codebase converting from MS SQL Server to Postgres would need to have every instance of CTE use evaluated for performance. [0] The previously linked deck highlights only some advanced excerpts of the SQL standard. The venn diagram of supported SQL constructs is much more overlap than exclusive.