5. SQL Server supports indexes on computable columns [1]
6. CLR Integration allows you to write a lot of things in C# (or VB.NET) [2]
10. Unicode is there by default if you use nchar/nvarchar/ntext columns, there's no problems unless you choose to use char/varchar/text instead
[1] http://msdn.microsoft.com/en-us/library/ms189292(v=sql.90).a...
[2] http://msdn.microsoft.com/en-us/library/ms254498(v=vs.80).as...
> 6. CLR Integration allows you to write a lot of things in C# (or VB.NET) [2]
You can also use a Mono plugin at Postgres, just like Perl, Python, C, C++, Lisp, Haskel, R-Cran... But it's not that, #6 was about the core functionality of the DBMS changing. For example, you can add new index types at Postgres with plugins, and people do add them. Once somebody wrote a plugin for manipulating SQL queries at what was at the time an object oritented database called Postgres. That's how deep you can go.
> 10. Unicode is there by default if you use nchar/nvarchar/ntext columns, there's no problems unless you choose to use char/varchar/text instead
Yeah, Unicode is used by default if you tell the DBMS to use Unicode... Thus, it's not the default. I'd agree that this is not a big problem.
False. Positively false. Because there is no default. Whenever you create a new column, which incidentally should contain text, you need to choose a type for that column. There is no default column-type. You need to be specific about how your data gets stored. That's why it's called a schema.
And when making that choice, for your column which will contain text, you must ask yourself two questions:
1. What sort of capacity is needed?
2. Are you living in the 1980s or in the year 2013? If your answer is the latter, you always choose Unicode unless you can argue for why it wont ever be needed. That's all.
In 2013 you don't have to argue for the need for Unicode. You have to argue for the right to use antiquated, primitive 8-bit text-types. And then you choose (because you and noone else will have to choose that column-type) Unicode text-types by default.
Anything else is madness. If any tool you rely on to do this for you chooses non-Unicode by default it is broken and needs to be fixed.
There might be a million other things SQL Server should address, but this is not one of them. Nothing is wrong with text-support.
1. Read Committed is not that restrictive to be honest. If you're short on memory it can be an issue but even in a high frequency system it should only lock at the row level. Beyond that, why would you be pushing to read dirty data? That's an issue in and of itself.
8/9. Arrays? JSON? XML? It's not relational data. Either parse it or put it in a different system, no RDBMS is going to handle these very well because they break the 'Relational' part. They might be accomodated, but trying to work with them is not a good idea in the vast majority of cases. I'm promoting SQL here and I still have to point out that SQL handles XML like crap too, try and index an XML blob.
To be fair SQL Server has constructs for this, but they are plenty in types and awful in nature. They are even worse to understand how they work and interact together and how they will optimize your queries.
And I guess maybe that was your point?
Handling XML in SQL was "reasonable" when the option was full fledged, tripple-verbose DOM code in compiled languages. These days though, you have better ways of "shredding" XML into usable data-constructs and the desire to do anything of that sort inside the DB is definitely approaching zero.