Comments 17
Больше всего понравились — столбцы идентификаторов
Add identity columns for assigning a numeric value to columns on insert (Peter Eisentraut)
These are similar to SERIAL columns, but are SQL standard compliant.
Identity column — это очень хорошо. Но если сделать insert в таблицу с конкретными primary key, счетчик увеличится сам?
Нет ли ограничений на вставку в такие таблицы, как в sql server?
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]
This clause creates the column as an identity column. It will have an implicit sequence attached to it and the column in new rows will automatically have values from the sequence assigned to it.
The clauses ALWAYS and BY DEFAULT determine how the sequence value is given precedence over a user-specified value in an INSERT statement. If ALWAYS is specified, a user-specified value is only accepted if the INSERT statement specifies OVERRIDING SYSTEM VALUE. If BY DEFAULT is specified, then the user-specified value takes precedence. See INSERT for details. (In the COPY command, user-specified values are always used regardless of this setting.)
The optional sequence_options clause can be used to override the options of the sequence. See CREATE SEQUENCE for details.
Спасибо за труд автору, будет ли примеры по логическому репликации?
Заранее спасибо!
Более сильная проверка подлинности, основанная на SCRAM-SHA-256
Оригинал:
Stronger password authentication based on SCRAM-SHA-256
Что соответствует:
Более сильная проверка пароля, основанная на SCRAM-SHA-256
Одно слово, а смысл несколько меняется, не находите?
postgrespro.ru/docs/postgresql/10/index.html
В его составе есть перевод и этих замечаний к выпуску:
postgrespro.ru/docs/postgresql/10/release-10.html
Если в сегменте wal есть несколько записей, после чего активности или записей в wal нет долгое время, как обеспечивается сохранность уже записанных в wal транзакций, ведь если на диске где находится wal произойдёт сбой, онлайновые wal могут быть потеряны. Я тут вижу выход например в запуске принудительного переключения wal с последующей архивацией.
Если кто хочет собирать новый постгрес при помощи CMake и возможно Ninja то вы можете попробвать эту ветку:
https://github.com/stalkerg/postgres_cmake/tree/cmake_rel10
или патч
https://gist.github.com/stalkerg/9da894195628d24b3cf25f399af3714e
Там же вы найдёте как можно собрать постгрес под Windows без захода в консоль вообще.
Все функции PG_FUNCTION_INFO_V1 автоматически маркируются атрибутом DLLEXPORT на Windows (Laurenz Albe). Если сторонний код использует декларацию extern функции, он так же должен использовать отметку DLLEXPORT для таких деклараций.
Наконец мои стекнания косвенно но привели к результату. Правда я всё ещё хотел бы видеть контриб модули как "плагины" и внятный API со стороны постгреса.
Добавлена индексная поддержка в btree_gist для типа данных UUID (Paul Jungwirth).
Я джва года этого ждал! Наконец-то можно использовать многоколоночные exclude constraints для внешних ключей к таблицам с первичным UUID-ключом (ну и вообще с UUID колонками)
Очень хотелось бы стандартного бинарного выходного плагина для логической репликации. У меня есть мысль использовать логическую репликацию для ETL вместо надоевшей уже глючной таблицы change_log которую заполняют триггеры — но одинаково не хочется ни парсить инструкции INSERT регулярками, ни писать свой плагин.
Декларативное партицирование закладывает хороший фундамент для будущих улучшений в этой области. Есть надежда, что существующие проблемы уйдут в прошлое, и будет меньше головной боли с партициями.
То что сделано сейчас имеет весьма сомнительную ценность. На мастер таблицу нельзя навесить триггеры (уровня строки делающие проверки на on conflict например), индексы и все прочее добро. При создании партиций соответственно наследуется только структура, все что можно было унаследовать при триггерном партиционировании от мастера теперь надо прикручивать руками. В том числе и первичные ключи. Для создания годовалой секции это может и не критично. Но если это делать ежедневно, то будет напрягать. Особенно количество триггеров. На каждую секцию свой, вместо 1-го на мастер таблице. А пока к сожалению убрав одну проблему, сделали 10 новых. Остается ждать что может что нибудь изменится в подходе к партиционированию, а пока использовать старые методы. То что имеем сейчас, мало пригодно для использования в условиях ежедневного создания секций по нескольким десяткам таблиц. И предобработкой данных перед вставкой. Хотя для меня казалось что очень логично вешать триггер на мастер таблицу и применять его ко всем партициям.
Для вас делают https://github.com/postgrespro/pg_pathman, возможно, что его потом втащат в ядро и соединят с новым синтаксисом партиционирования.
Встречаем PostgreSQL 10. Перевод Release Notes