Как стать автором
Обновить

Комментарии 23

PostgreSQL является SQL-совместимым (SQL: 2011) и полностью соответствует требованиям ACID

Меня тут сейчас заминусуют как обычно, но это всё неправда, конечно:
  • С примерами несоответствия PostgreSQL SQL стандарту можно ознакомиться здесь
  • пример несоответствия D в ACID — печально известные bitmap индексы
  • с примерами несоответствия I в ACID можно ознакомиться здесь

И это навскидку, наверняка можно накопать ещё примеров. Просто никто этим никогда не занимался. Все больше любят громкие красивые утверждения.
Аргументированная критика это хорошо и, возможно, это все действительно неправда, но вы действительно считаете что данные ссылки все разъясняют:

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.»

* при этом замечу что как раз функции (пример: clock_timestamp()) ведут себя ожидаемым образом

и т.д.

ps: я бы еще не отказался почитать о печальной известности bitmap-индексов постгреса
Я перечитал это сообщение несколько раз, но так и не понял, что вы хотели сказать. Что я не прав, то есть по ссылке есть примеры несоответсвия PostgreSQL стандарту SQL? Или что я не прав, то есть по ссылке нет примеров несоответствия PostgreSQL стандарту SQL? Или смешная третья опция?

Про bitmap индексы всё просто: они не журналируются в WAL. Поэтому для них durability не существует. И репликации тоже.
  1. у постгреса транзакционный DDL, он откатывает транзакцию полностью
  2. функции для получения timestamp в транзакции есть и работают корректно
  3. у постгреса нет bitmap индексов
  4. и т.д.


очень, мягко скажем, противоричивый источник правды

Источник правды там нормальный. Я знаком с человеком лично — это ходячая энциклопедия по SQL стандарту. Это человек, которого можно разбудить ночью, и спросить про любой произвольный аспект SQL стандарта. И он подробно расскажет, с примерами и аспектами реализации в разных СУБД. А ещё этот человек автор книг по SQL стандарту. Просто вы в статье пытаетесь прочитать то, чего там нет. Статья утверждает, что MySQL в некоторых вещах лучше соответствует SQL стандарту. А я статью привёл потому, что там действительно есть примеры несовместимости SQL стандарта и PostgreSQL.

Да, я говорил про hash индексы, естественно, просто закоротило провода. Но на Хабре нельзя редактировать комментарии. И т. д.

Статья все равно жёлтая: обсуждение соответствия стандарту без ссылок не то что, на сам стандарт, а даже на его название.

Ну не учёл человек, что к нему строгие эксперты с Хабра придут. Иначе бы он конечно по всей форме доложился. С ссылками, цитатами и названиями стандарта.
А можно немного подробнее почему в первом примере вообще должно произойти сохранение записей в таблицу? Даже если DDL транзакционный у Postgresql, а Mysql нет, ожидаемое поведение вероятно откатывание всех операций DML.
А можно оффтоп вопрос в студию — MySQL уже научился каскадно триггеры запускать? Или каскадно удалять? Сравнивать базы, для одной из которых можно привести пример, как она НЕ соблюдает стандарт, со второй, к которой обычно приводят примеры как она МОЖЕТ соблюдать — минимум странно.

PS И да, что там с документацией, какой-нибудь прогресс есть? Без подначки, может у кого-то из форков выправили ситуацию? Год назад у оригинала было так же всё плохо.
А я здесь никаким сравнением MySQL и PostgreSQL не занимаюсь. Это у вас какой-то каскадный триггер на ключевые слова сработал. Я говорю, что два утверждения из статьи не соответствуют действительности и привожу примеры. PostgreSQL сообщество любит тиражировать такие байки.

По поводу оффтопа — я могу вам рассказать о гораздо более серьёзных проблемах в MySQL, чем каскадные триггеры. Собственно, я это уже делал на Хабре и в докладах. Но действительно оффтоп же.

Пришлось тут связаться с 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;
А я кстати совершенно не спорю с утверждением «PostgreSQL лучше соответствует SQL стандарту, чем MySQL». Я кстати уже об этом писал.

Но это же совсем не то, что PostgreSQL сообщество любит говорить. PostgreSQL сообщество любит говорить «PostgreSQL является SQL-совместимым» («PostgreSQL is SQL-compliant» в оригинале). Это враньё. И rdruzyagin это знает, но старательно это враньё переводит.
Как главный провокатор и распространитель вранья, прокомментирую)

Алексей, рад вас видеть, мы тут как раз планировали вас пригласить к нам в гости предстоящим летом :) Надеюсь, что вы согласитесь.

По существу теперь. Соглашусь, что утверждение про полноценный ACID является преувеличенным, и, вероятно, мне стоило добавить примечание переводчика на этом месте. Посыпаю голову пеплом)

Насчет стандарта, в тексте написано, что «PG является SQL-совместимым», а не «PG строго соответствует стандарту SQL». Или я не прав, и эти два выражения надо отождествлять? Какова позиция строгих экспертов Хабра по данному вопросу (by the way, наименование стандарта, SQL:2011, он же ISO/IEC 9075:2011, все-таки упоминается в тексте, пускай и без прямой ссылки)?

Насколько я могу судить, примерно то же самое пытаются изложить разработчики СУБД в этом разделе документации: https://www.postgresql.org/docs/current/static/features.html

Я безмерно благодарен за вашу критику, Алексей, в будущем наша команда будет более внимательна в подборе материалов)
наименование стандарта, SQL:2011, он же ISO/IEC 9075:2011, все-таки упоминается в тексте, пускай и без прямой ссылки

Извиняюсь, если я был не правильно понят.
Когда я говорил про отсутствие наименования стандарта, речь шла про статью: http://ocelot.ca/blog/blog/2013/09/30/sometimes-mysql-is-more-standards-compliant-than-postgresql/

Понял, значит это я некорректно истолковал ваши комментарии. Внезапно развернувшаяся баталия на тему MySQL vs. PostgreSQL сбила меня с толку.
Роман, спасибо за развёрнутый ответ!

На мой взгляд, нельзя соответствовать стандарту «нестрого». Стандарту можно либо соответствовать, либо нет. Поэтому утверждение «PostgreSQL is SQL-compliant (SQL:2011)» из оригинальной статьи ложно. А утвеждение из официальной документации «PostgreSQL supports most of the major features of SQL:2011» истинно. С другой стороны, утверждения «It is fully ACID compliant» и «Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard» отсюда снова ложные.

Про упоминания названия стандарта — это претензия относилась не к данной статье, а моей ссылке. Если я правильно понял.
ОК, позиция ясна и аргумент принимается. По вопросу ACID я полностью согласен, по вопросу конформирования стандарту — не совсем, но смысла спорить не вижу :)

В дальнейшем мы постараемся обращать внимание читателя на подобные огрехи, чтобы провоцировать более вдумчивое осмысление материала и стремление к более обстоятельному изучению рассматриваемых вопросов.
Хотел бы пояснить своё мнение по соответствию стандарту. Если принять, что фраза «PostgreSQL является SQL-совместимым (SQL:2011)» на самом деле означает «PostgreSQL соответствует SQL:2011 нестрого, в некоторой степени», то в этом же самом смысле можно сказать и «MySQL является SQL-совместимым (SQL:2011)». Ведь соответствует же. Нестрого, в некоторой степени, хоть и в меньшей, чем PostgreSQL. Поэтому я считаю, что с терминами нужно аккуратнее, это важный вопрос.

Поясните, в каком месте в статье описана именно эволюция отказоустойчивости? Эта статья — описание конкретной технологии, основанной на широко распространённой идее бинарных логов транзакций, вовсе не уникальной для PostgreSQL — та же MySQL, с которой его постоянно зачем-то сравнивают, умеет Point-In-Time Recovery с помощью своих Binary Log.


Под эволюцией я бы понял, например, такое: была тупая база, крошилась при неожиданном убивании процесса. Потом это она научилась переживать, стала крошиться только при переполнении диска. Потом с этим научились бороться, но при внезапном отключении питания всё-таки данные портились. Потом и с этим научились бороться. А потом появился мульти-мастер кластер, можно писать на любую ноду, читать с любой ноды, если одна из них выйдет из строя — никто не заметит, т.к. остальные ноды подхватят всю нагрузку. Но в статье же ничего похожего нет.

Эта статья — первая из цикла статей, посвященных вопросу. В ней рассматриваются более фундаментальные аспекты архитектуры СУБД. Следующие выпуски будут освещать развитие иных средств из числа доступных пользователям PostgreSQL, не охваченных в текущем выпуске. Всего будет 4 публикации. Но того уровня детализации, который вы ожидаете, точно не предвидится, вынужден разочаровать.

Я заметил, что предполагается цикл статей. Я протестую против слова "эволюция" в заголовке. Эволюция — это то, как что-то там изменялось со временем. Вы про это, как менялось, собираетесь рассказывать? Если нет, то это не эволюция.


Ну и, какой бы там ни предполагался цикл статей, вот этот заголовок относится к этой конкретной статье. И ей не соответствует.

Собираемся, конечно. Например, в следующей статье будет короткий экскурс в историю становления возможностей репликации в PostgreSQL.

Заголовок меняться не будет, из песни слов не выкинешь. Это перевод существующей публикации.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.