It would be even better if it pointed out the various other quirks and oddities that MySQL has that Postgres doesn't, like this one I talked about in my previous post here: http://mwrynn.blogspot.com/2018/09/my-coworker-recently-came-up-to-me.html
Or, about how the MySQL query planner is pretty much inferior.
Or, if it talked about WHY each of these features in this huge list are useful things. I thought I'd write here about one, single Postgres feature that it is incredibly useful:
Transactional DDL: This is a really big one for me, particularly with respect to SQL scripts and rolling out incremental schema changes. Let's say I want to apply the following changes to an existing schema, to upgrade it from schema version i to schema version i+1:
0. begin;
1. insert into table x;
2. create table y;
3. insert into y;
4. alter table z add column abc;
5. update z set abc = ...;
6. commit;
In Postgres I can roll out this whole set of statements in an all or nothing manner. In MySQL (and to be fair, some other databases as well), if say statement #5 fails for ANY reason - could be a bad foreign key reference, lack of disk space, or anything else - errors can and will happen - I'm stuck with a partially applied set of changes. What if the insert (statement #1) only makes business sense in conjunction with the update in the last statement? Well too bad, because statement 3 (alter table) forced a commit. So now there's "bad data" on prod until I have a chance to manually revert everything.
In Postgres it goes like this: Uh oh, statement 5 failed? Roll it all back! We're back at schema version i, not schema version i + random mess, where random mess != 1. Ta-da!