Насколько я вижу, это не один, а два варианта REPLACE. Первый, в Sqlite, применяется в описании констрейнтов, например как PRIMARY KEY ON CONFLICT REPLACE . Пока этого нет в стандарте SQL, в постгресе тоже это не появится, тем более что аналогичную конструкцию можно применять в INSERT, см https://postgrespro.ru/docs/postgresql/15/sql-insert
Второй, из MariaDB - это другая конструкция, тоже не из стандарта SQL, поэтому вряд ли её можно ожидать в постгресе. Тем более, что есть вышеупомнятуый INSERT...ON CONFLICT UPDATE, и с 15й версии соответствующий стандарту SQL более универсальный MERGE https://postgrespro.ru/docs/postgresql/15/sql-merge
Аргументация проста — производительность. Любители хайлоуда даже смывают краску с серверов (шутка). В реальности есть много баз, в которых нет (или почти нет) констрейнтов. Часто целостность пытаются обеспечить на уровне ORM. Например, так делает JIRA.
Расписание будет очень скоро, возможно, сегодня. Конференция будет идти 1,2 и 3 марта целый день, примерно с 10:00 до 19:00 (в последний день — меньше), с перерывом на обед.
Об этом надо спросить авторов документа, а не обсуждаемой статьи. Спрашивайте.
поскольку это рекомендации, а не правила, «и т.п.» вполне допустимо, хоть и не однозначно.
Идеи мне неизвестны. Если речь об обсуждаемом документе ЦКИТ, правильнее спросить об этом у его авторов. Morigh, что они ответили?
Мое субъективное мнение — речь об ограничении наклеивания шильдиков.
Но это методические рекомендации, а не правила Реестра.
Почему-то автор забыл дать ссылку на самую авторитетную информацию:
https://www.postgresql.org/about/press/faq/
https://www.postgresql.org/docs/current/history.html#HISTORY-POSTGRESQL
Так что - надо просто говорить "Постгрес" или "post-GRES-que-ell", это правильно и грамотно.
А что идея соединить "Postgres" и SQL в одном слове была сомнительной - это понятно. Надо сказать, сообществе были споры об этом, см вот тут https://youtu.be/LlIEboRi4m8?t=1555, но англоговорящее большинство решило так, как решило.
А вообще, отличные задачи.
В локали
en_US неделя должна начинаться с воскресенья.Просто зарегистрируйтесь. Напишите на info@pgconf.ru, что Вы студент. На стойке регистрации покажите студак.
Да, программа реально набралась отличная.
Специально питонячьих докладов никто не подавал. Но, возможно, что-то из утилит, о которых будут рассказывать, написано на нём.
Раньше на PgConf бывали доклады о питоне -
https://pgconf.ru/202110/309195, https://pgconf.ru/2019/118178, https://pgconf.ru/2019/118174,
https://pgconf.ru/2021/288550 и https://pgconf.ru/en/2021/288548 (от разработчика psycopg2)
и многие другие.
Очень сложный. Трудоемко поддерживать и особенно мёрждить новые изменения из апстрима постгреса.
Насколько я вижу, это не один, а два варианта REPLACE.
Первый, в Sqlite, применяется в описании констрейнтов, например как PRIMARY KEY ON CONFLICT REPLACE . Пока этого нет в стандарте SQL, в постгресе тоже это не появится, тем более что аналогичную конструкцию можно применять в INSERT, см https://postgrespro.ru/docs/postgresql/15/sql-insert
Второй, из MariaDB - это другая конструкция, тоже не из стандарта SQL, поэтому вряд ли её можно ожидать в постгресе. Тем более, что есть вышеупомнятуый INSERT...ON CONFLICT UPDATE, и с 15й версии соответствующий стандарту SQL более универсальный MERGE https://postgrespro.ru/docs/postgresql/15/sql-merge
Который реплейс?
Что за заявка, какова причина отказа?
поскольку это рекомендации, а не правила, «и т.п.» вполне допустимо, хоть и не однозначно.
Мое субъективное мнение — речь об ограничении наклеивания шильдиков.
Но это методические рекомендации, а не правила Реестра.