Comments 6
Про tenant_id поясните пожалуйста ?
Имелось ввиду, что есть таблица tenants и во всех остальных таблицах условно employees первичный ключ составной ? Но че то не догоняю как фича set null тут помогает ? Поле осталось частью первичного ключа и не может быть null. Или в 15м пг семантика поменялась и это совмемстно с nulls distinct работает ?
Немного сумбурно сформулировал возможно. Я не понимаю, как фича set null помогает в случае бд которые используются разными клиентами.
Имелось ввиду, что есть таблица tenants и во всех остальных таблицах условно employees первичный ключ составной ?
Да.
Я не понимаю, как фича set null помогает в случае бд которые используются разными клиентами.
Суть патча в том, что после ON DELETE SET NULL в скобках можно прописать список столбцов, которые нужно сбросить в NULL и не включать в него tenant_id.
подумал еще понял про что речь.
пусть есть Таблицы
office(id pk, tenantid pk, name)
Employee(id pk, tenantid pk, officeid fk,name) fk(tenantid, officeid) ref offices
Тогда да, понятно что происходить будет. У меня просто в проектах не такое четкое разделение по клиентам и поэтому было бы два tenantid, вот и тупанул.
а так согласен, если у кого то есть разделение такое типа мой склад фича полезная.
"NULLS NOT DISTINCT" - отличная штука, приятно видеть что эту проблему решили. Можно будет выпилить пачку костылей эмулировавших это поведение для корректных upsert'ов.
Сейчас использую UNIQUE индекс по (column IS NULL, COALESCE(column, 0)) - это даёт аналогичное поведение.
Как пишет автор патча Питер Эйзентраут, это изменение включено в свежий проект стандарта SQL. Вероятно многие производители СУБД будут поддерживать такой синтаксис. Постгрес уже в их числе.
PostgreSQL 15: Часть 4 или Коммитфест 2022-01