Может будут какие-то идеи. Есть таблица t1, в ней есть аттрибут number (primary key), другие аттрибуты и аттрибут deleted "boolean", дефолтное значение false. На основании таблицы t1 сделано вью v1, которая показывает все строки таблицы кроме тех, в которых deleted "boolean".
Столкнулся с проблемой. Пользователь вводит создаёт запись с number, потом "удаляет" созданную запись (т.е. поле deleted становится true). Она пропадает из v1, но остаётся в t1. Соответственно - при попытке снова создать запись с тем же number - мы сталкиваемся с тем, что в v1 - она есть, а в t1 - нет, т.е. пользователь думает, что может создать запись с таким номером. Решение "влоб" - при валидации number проверять его по t1, но это некрасиво.

Что бы хотелось сделать - при попытке создать запись с тем же номером, если такой номер существует и deleted 'true' - то мы обновляем запись, в т.ч. "восстанавливая" дефолтное значение аттрибута deleted, если же 'deleted' false, то такую операцию мы не выполняем.

Триггер на view INSTEAD OF INSERT с INSERT ... ON CONFLICT DO UPDATE внутри, может быть?

Когда первичный ключ не первичный ключ — это безобразие.
Отымите первичный ключ у number и сделайте отдельный первичный ключ сбоку, который будет выдаваться сиксенсом, а не приложением.
Для пущей консистентности можете сделать на t1 уникальный индекс по (number, deleted).

Гм, фигню предложил. По (number) where not deleted.

да, примерно так. только следует помнить, что частичный уникальный индекс не может использоваться для FK и логической репликации (не ключ)

> Когда первичный ключ не первичный ключ — это безобразие.

Вообще, да. Но вот это:

> сделайте отдельный первичный ключ сбоку, который будет выдаваться сиксенсом, а не приложением.

Это карго-культ, а не решение, извините. См. http://www.databasesoup.com/2015/03/primary-keyvil-reprised.html

Если вы про то, что первичный ключ в t1 не нужен, то у меня есть универсальная отмазка: у меня ORM без первичных ключей не робит.

Нет. Я про то, что имитация первичных ключей (как и имитация радиовышек из кокосовых пальм и соломы в настоящих карго-культах) менее, чем бесполезна. Опять-таки, см. статью.
А в данном случае нормальным решение могло бы быть изменение схемы / модели, возможно (а может, и нет — задачи я не видел).

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

Всем привет, как можно создать Уникальный индекс по полям, которые могут иметь null'евые значения
Знаю, что null != null
Всего полей = 8.  два из которых double, остальные int
посмотрел тут, в особенности последний рецепт, но возниклы траблы с cast
https://pgcookbook.ru/article/unique_index_with_nullable_columns.html

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

DELETE будет действительно удалять из t1, на него будем вешать триггер, что при удалении -  удалённая строка попадает в t2, в которой number это уже не PK, куда мы также можем сохранить время удаления для упрощения поиска.

Вам один индекс по всем 8 полям нужен? Если нет, то почему не решение №2 (частичные индексы)?

я пока временно сделал null равным -100, ибо это только во время обработки нужно
потом можно будет вернуть null

Помогите пожалуйста )))

Все было нормально и тут бац такая фигня

Там написано, что сервер не принял подключение и советуют проверить, работает ли он.

Так сервер это мой пк получается ))

Тем проще проверять.

Он работает это локалхост