Эволюция отказоустойчивости в PostgreSQL

START TRANSACTION;
CREATE TABLE t (s1 SMALLINT);
INSERT INTO t VALUES (1);
INSERT INTO t VALUES (32768); /* This causes an error. */
COMMIT;
SELECT * FROM t;

Result:
MySQL finds a row containing 1. PostgreSQL finds nothing.
Reason:
PostgreSQL rolls back the entire transaction when it encounters a syntax error. MySQL only cancels the statement.

CREATE TABLE t (s1 INT);
INSERT INTO t VALUES (1);
COMMIT;
START TRANSACTION;
SELECT CURRENT_TIMESTAMP FROM t;
/* Pause 1 second. */
SELECT CURRENT_TIMESTAMP FROM t;

Result: PostgreSQL shows the same timestamp twice. MySQL shows two different timestamps.
Reason:
PostgreSQL keeps the same time throughout a transaction; MySQL keeps the same time throughout a statement.
The key sentences in the standard say that the result of a datetime value function should be the time when the function is evaluated, and «The time of evaluation of a datetime value function during the execution of S and its activated triggers is implementation-dependent.»

Пришлось тут связаться с mysql, после уже долгой работы с postgresql. Как же я рад, что постгре "не саблюдает" стандарт, и DDL тоже транзакционно выполняет. Очень не удобно откатывать половину миграции, если 2я половина дала сбой.

И case-sensitivity тоже радует.

У меня, кстати, сложилось впечатление, что ни одна СУБД полностью не соответствует SQL стандарту.

Касательно статьи, можно упомянуть более простой случай, где MySQL не соответствует SQL92.
Речь идет про абзац:

13.9 <update statement: positioned>

6) The <value expression>s are effectively evaluated before updat-
   ing the object row. If a <value expression> contains a reference
   to a column of T, then the reference is to the value of that
   column in the object row before any value of the object row is
   updated.

И иллюстрируется запросом:

UPDATE foo SET a = b, b = a WHERE id = 42;

Беда в том, этот запрос в MySQL эквивалентен:

UPDATE foo SET a = b, b = b WHERE id = 42;