News for hackers. Stuff that matters.
Re:SQL Reserved Words – The Empirical List by MarkusWinand on Wednesday October 11, 2023 @02:12PM (#37848133)
I wonder why you are so focused on SQL:2011? Since then there was SQL:2016 and now there is SQL:2023.

Also, which features in particular are you missing in PostgreSQL? Merge was added with PostgreSQL 15 a year ago: https://modern-sql.com/caniuse/merge

Re:SQL Reserved Words – The Empirical List by refset on Wednesday October 11, 2023 @03:43PM (#37849321)
Temporal tables, most likely. Although even SQL Server only supports system time versioning, not full bitemporal tables (as per the spec).
Re:SQL Reserved Words – The Empirical List by MarkusWinand on Wednesday October 11, 2023 @04:07PM (#37849614)
The existing implementations (Oracle DB, SQL Server, MariaDB, Big Query) come with their problems too. I was a big fan of the new features when it came out in 2011, but pratically there is an unsolved elephant in the room: It doesn't cover schema changes.
Re:SQL Reserved Words – The Empirical List by refset on Wednesday October 11, 2023 @04:47PM (#37850048)
> there is an unsolved elephant in the room: It doesn't cover schema changes.

100% agreed. It's remarkable how Datomic also arrived on the scene in the same era (2012) but actually managed to solve a lot of these hard issues of immutable versioning + schema evolution via a clean EAV-based information model and an emphasis on accrete-only schema changes.

I'm a big fan of your work by the way :)

Re:SQL Reserved Words – The Empirical List by rjbwork on Thursday October 12, 2023 @11:24AM (#37858524)
2016/2023 got pretty widespread support across databases for the functionality I care about, both before and after adoption - namely the JSON stuff. MSSQL also already had pretty good graph support AFAIK, although I haven't used it that much.

I find the temporal table stuff really useful and they drastically simplify a number of requirements, so it's annoying that the only non-proprietary DB that supports it is maria.