ммм, тогда наверно индекс все же должен быть уникальным ?
может этот сервис эксцепшены ловит на вставку уникальных значений ?

Да, срабатывает эксепшен СУБД на вставку неуникальных значений. Надо что бы вставка прошла.

Удалите старое значение )

Делать вообще нечё нельзя, сторонне ПО, оно как работает так и работает )

Так надо что-то сделать ? (Чтобы вставка прошла)
Или нельзя ничего делать ?
Вы уж определитесь

Нужно сделать, что бы Postgres пропустил неуникальную вставку

Тогда нужно удалить уникальный индекс
Или отключить, что почти ровно удалить
Другого путя нет )

Нет.

> Надо что бы вставка прошла.

Зачем?

> Нужно сделать, что бы Postgres пропустил неуникальную вставку

Т.е., может, на самом деле не нужно? ;)

Только сейчас нашлась минутка, ну да лучше поздно чем никогда. Функции по умолчанию создаются с параметрами "VOLATILE PARALLEL UNSAFE" что дает указание планировщику даже не рассматривать варианты распараллеливания плана. Если функция только выбирает данные и предполагается к использованию в SELECT в качестве элемента запроса необходимо изменить данные параметры на "STABLE PARALLEL SAFE " В противном случае можно забыть о преимуществах параллельных планов. Решил что без упоминания об этом наш диалог будет несколько однобоким.

Не суть, вопрос простой, можно ли отключить проверку эту на уровне ПГ. Других вопросов нет.

Just saying: не всякую функцию, которая "только выбирает данные", можно объявлять STABLE, т.е. лучше прочитать документацию при параметры.

Ошибиться можно по разным причинам, но компилятор слона в этом отношении стоит  на страже так сказать

В случае  если вы радикально не правы получите что то воде этого.

Обошёлся pg_dump для базы и pg_dumpall для пользователей и ролей.

Не очень-то он "на страже" (потому что это всё равно неразрешимая задача), а предупреждения / ошибки выдаются только в некоторых крайних случаях.

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

Просто pg_dumpall был бы проще... но, возможно, куда медленнее выполнялся бы. ;)

Это конечно так, всему свое место и время. Это вопросы больше касаются здравого смысла. Просто речь шла о 95% порте. Стоит в этом случае упомянуть о том что можно в принципе потерять возможность к параллельному выполнению не осознавая этого факта.

text после определённого размера поля начинает храниться в отдельной таблицэ (читать по ключевым словам postgresql toast, если интересно).

В данном случае alter table убирает необходимость в toast для этого столбца — потому pg_table_size её перестаёт видеть и учитывать.

Баг в pg_table_size, видимо.

Про тоаст знаю, но тут именно создается новый файл и туда переливаются данные.
Для int -> bigint то же самое. Если интересно, файлик с экспериментом