Re: Referential Integrity Checks with Statement-level Triggers

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Referential Integrity Checks with Statement-level Triggers
Дата
Msg-id CADkLM=c22S2s6UjSCVjkfAKBaMAO8hyD9UB4qF96t5cu8czaCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Referential Integrity Checks with Statement-level Triggers  (Antonin Houska <ah@cybertec.at>)
Ответы Re: Referential Integrity Checks with Statement-level Triggers  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

In order to avoid per-row calls of the constraint trigger functions, we could
try to "aggregate" the constraint-specific events somehow, but I think a
separate queue would be needed for the constraint-specific events.

In general, the (after) triggers and constraints have too much in common, so
separation of these w/o seeing code changes is beyond my imagination.


Yeah, there's a lot of potential for overlap where a trigger could "borrow" an RI tuplestore or vice versa.

The people who expressed opinions on nuking triggers from orbit (it's the only way to be sure) have yet to offer up any guidance on how to proceed from here, and I suspect it's because they're all very busy getting things ready for v12. I definitely have an interest in working on this for 13, but I don't feel good about striking out on my own without their input.
 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Should we increase the default vacuum_cost_limit?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Remove Deprecated Exclusive Backup Mode