AlterEgo20

As for number 5 - Postgres already does that. This feature is called "constraints". Such constraints can be applied to multiple columns and are used to build better query plans (as well as limiting DML operations)

Even a single rare rollback can kill a prod DB. We had a situation when a bug in our code caused a series of huge UPDATEs in Oracle DB and LOCKed some critical tables. After ~2 hours we found this session and killed it.

The problem - we had to wait for 2 more hours with dead prod while Oracle was rolling back everything. In Oralce killed sessions still hold their locks while rolling back.

In Postgres rollback is almost instant.

There is not suck thing as "NoSQL store". NoSQL is just a buzzword that is used to describe dozens (hundreds?) of very different solutions.

Google "Postgres BDR". It is new, but it allows you to replicate changes on master to another master. With some configuration it can even change replicated data.

Any SQL DBMS is able to store and handle NUMERIC data type. It is a binary decimal with any precision you may want.

Some of the DBMS's also have dedicated currency types.

Easy. Just use dblink or foreign table to execute part of the statement inside other transaction. dblink to the same server/db is often used as way to create an "AUTONOMOUS_TRANSACTION"

Why `nohup postgres 2>&1 > postgres.log &` instead of `pg_ctl start`? You could also use `pg_ctl -w start` to wait for proper server startup instead of `sleep 2`

"modern development frameworks can handle data integrity stuff". Wrong. They cant. If you have 2+ applications working with the same db, there will be problems with data integrity that no "modern development framework" can solve.

"one view per user" - you can have a single VIEW, that filters rows based on user name ("owner_user_name" column in the base table). Or use some kind of mapping table for "user_name" <-> "table PK id". It gets more complicated with inherited user roles, but still manageable.

There are `security_barrier` VIEWs. They give a "way of restricting a given connection/user to only rows with the right foreign key in a table". Still you have to create them all (not a simple task for complex DB scheme).

Yep. Damn auto correct.

Postgres has transactional DDL and DML. If anything fails - everything is rolled back.

Hm. "rows actually not being written to the db during normal circumstances". A database that acts like /dev/null ? Like BLACKHOLE MySQL storage engine? I can not imagine a real use case, where it will be needed. If you allow a database to lose "some" rows it may well lose all of them. What is the purpose of a database that does not store your data?