RTFMTriggers that are specified to fire INSTEAD OF the trigger event must be marked FOR EACH ROW, and can
only be defined
on views .
PCContraЕсть таблица
1.
logs.pidlist (pid INT NOT NULL UNIQUE, pnum INT NOT NULL UNIQUE);
В таблицу поступает только команда INSERT.
Не могу написать триггер, который бы проверял перед вставкой, есть ли такие значения уже в таблице. Если есть, то удалял бы их, а новые вставлял.
Например, если уже есть такой pid, или pnum, или и то и другое, то удалить такие строчки, новую вставить в любом случае. И после этих действий выполнял бы вакуум таблицы.
Я сам мало этими командами занимался, опыта совсем нет по ним.
Спасибо за внимание
извините, сразу не вчитался.
у вас 2 потенциальных ключа. а не ключевой набор с ресурсами.
т.е. если pid уже есть, но с другим pnum, надо заапдейтить pnum при это pid-е. а если есть pnum с другим pid -- надо заапдейтить тот pnum (поменять ему pid). и, наконец если есть 2 записи -- одна с таким pnum а ДРУАЯ с таким pid -- надо выбросить ОБЕ старые ,и заложить новую . так, кажется следует из вашей постановки ? ничего не путаете ?
тогда всё немного сложнее .
Проще всего с помощью каскада безусловного DELETE | RETURN NEW; в BEFORE триггере. но вот с конкуренцией на инсертах (за оба ключа) надо побороться -- устроить на них очередь в момент входа в триггер -- т.е. еще даже перед DELETE. (чтобы delete опоздуна срабатывал только после коммита опередившей транзакции).
Это наверное удобнее сделать через pg_advisory_xact_lock(key1 int, key2 int)
вам надо залочить одним предложением 2 инта на разных ключах. т.е .взять в selecte 2 pg_advisory_xact_lock(2) с параметрами например oid pg_attribute-а -- первый параметр; и собственно значение этого поля -- второй. Поля у вас удачно -- интовые. были бы бигинты --пришлось бы что- то иное придумывать.
