Earlier quoted context omitted.
It makes some sense to me. I always find it pretty painful writing anything but the most simple queries in MySQL - for starters, there's no CTEs, no windowing functions, and no table-valued functions, all of which I find invaluable - and the query optimizer (and performance in general) seems... not so hot. As far as I can tell, the main reasons people use MySQL are 1) it's well-known, well-documented, free, and widel…
I used MySQL a lot at my last job (MS SQL Server now, which has its own ups and downs) and I examined using Postgres for some personal projects, and there's a few features that I used rather heavily in MySQL (partitioned tables and upsert are the really big ones) that Postgres doesn't have an out-of-the-box equivalent to. There's a lot of tradeoffs between the two, I think it's wrong to say one is better than the oth…
> As a final word – yeah, but why PostgreSQL doesn't handle it internally, as the other database?
> Answer lies somewhere between "developers have other things to do first" and "it's complicated, because there are many ways to do it, and the most correct one is slow – so there is a trade off decision to be made".
I'm not sure how upsert is implemented in MySql but given its reputation and the fact that it is open source; I would imagine the Postgres team has considered their solution and have decided it wasn't good enough for their standards.
Postgres may not have an out-of-the-box solution but there are solutions out there which are mostly pretty trivial functions. Although they may add a bit of bloat since it seems you'd need a function for each table you'd want to use upsert on.
[0] http://www.depesz.com/2012/06/10/why-is-upsert-so-complicate...