SQL Server has some interesting features. It has a much better alternative to pgadmin. You can write stored procs in C#. I would use postgres for most tasks but there are things unique to SQL Server.
It just occurred to me that Rust might be a really good fit for user defined functions in MySQL. I would never want to write in C or C++ myself, but with a nice crate that abstracts away and/or provides most the structures you might need to pass back and forth, I would be much more confident that if I got it compiling in Rust that it probably wouldn't blow up my database.
I mean, I think that's one of the major benefits of using C# over C or C++. You're not likely to segfault or buffer overflow, etc.
User defined functions[1] in MySQL are dynamic libraries which are loaded and then you attach a function name to. A common example might be a hashing function that you want the DB to understand.[2]
That said, I bet just about every database supports something similar (and postgres' equivalent has already been provided by a sibling comment).
Is there a database where you can write stored procedures in C or C++?
Most of them. SQL-like languages like Oracle's PL/SQL are preferred, not because of any security problems but simply because it's much easier, specially when working with data sets.
Possibly because MSSQL is 'better', or was. MS could pump almost unlimited money into its optimiser. Posgres doesn't have that and I've been informed a few years ago postgres wasn't as good. Maybe it's caught up now; I don't know as I've no experience with it.
Sigh. The usual downvotes because... why, you can pick holes in what I said, or some people's identity is so tied up with a piece of open-source software that they can't tolerate apparent criticism of it?
Fact: the optimiser in an SQL engine is almost the quintessence of it. If you don't understand that then you don't understand that the potential cost of the declarative nature of SQL.
Fact: SQL optimisers are complex.
New fact: microsoft has pumped fantastic amounts of cash into MSSQL. Posgres just doesn't have those resources (and other resources, such as the late lamented Jim Gray).
Other fact. Postgres CTEs were an optimisation barrier until PG11 or PG12 (https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-...). AFAIK MSSQL's CTEs have never been an optimisation barrier, and I've used them long enough to know. I'm also trying to understand the cost of MVCC, which PG uses but MSSQL now has as an option, to try and understand where that costs, because depending on the scenario, it will. PG does not have READ UNCOMMITTED.
Fact: The guy I quoted had used postgres on large data a while back and said it wasn't as good as MSSQL. He had experience, which is the bottom line. I also acknowledged this may have changed recently.
Other fact: I don't dislike postgres and recently have decided learn PG also, because, for very good reason, MSSQL has its problems (the ridiculous cost not being the only one).
Fact: If you just downvote me without explaining why, neither of us can learn anything.
Thank you for a helpful comment. I can see the initial comment wasn't sufficient now you've explained how it looks to you.
The 2nd post is harder to justify in a way. Some of it comes from experience, and understanding the behaviour of a merge join vs a loop join for example, and how much slower the latter can be if applied wrongly, which points to why the optimiser is so vital.
Edit: there's also the cardinality estimation (which can so easily go wrong), the dynamic programming for joins and the combinatorial explosion when it comes to ordering/reordering of inner joins, heuristic costs of using indexes vs not, etc.
Some of it was hearsay, but I stated it as such. Anyway, point taken, and thanks again.