Pull to refresh
57
0
Иван Панченко @x-wao

User

Send message

Почему-то автор забыл дать ссылку на самую авторитетную информацию:
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

Который реплейс?

Postgres Vision 2021, а не 2020
Аргументация проста — производительность. Любители хайлоуда даже смывают краску с серверов (шутка). В реальности есть много баз, в которых нет (или почти нет) констрейнтов. Часто целостность пытаются обеспечить на уровне ORM. Например, так делает JIRA.
Расписание будет очень скоро, возможно, сегодня. Конференция будет идти 1,2 и 3 марта целый день, примерно с 10:00 до 19:00 (в последний день — меньше), с перерывом на обед.
Это вряд ли, т.к. это а)рекомендации б)составителю заявки. На их основании физически невозможно отказать. Будет что-то другое.
Ну, теперь все заинтригованы: пройдет — не пройдет! (и как именно) Ждём продолжения.
А в чем личный опыт, обещанный в заголовке статьи? Из статьи так и не стало понятно.
Что за заявка, какова причина отказа?
Об этом надо спросить авторов документа, а не обсуждаемой статьи. Спрашивайте.
поскольку это рекомендации, а не правила, «и т.п.» вполне допустимо, хоть и не однозначно.
Идеи мне неизвестны. Если речь об обсуждаемом документе ЦКИТ, правильнее спросить об этом у его авторов. Morigh, что они ответили?
Мое субъективное мнение — речь об ограничении наклеивания шильдиков.
Но это методические рекомендации, а не правила Реестра.
Можно. Да, возможно, это действительно «дальше», но в другом направлении.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity