Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
От | Jan Wieck |
---|---|
Тема | Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled |
Дата | |
Msg-id | 45B93E33.6010601@Yahoo.com обсуждение исходный текст |
Ответы |
Re: Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled
Re: Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled |
Список | pgsql-hackers |
The experience with Slony-I has shown that a) different behavior of triggers and rules on a transactions origin and a replica is essential; b) mucking around with the system catalog to achieve this is futile. This would be even more catastrophic in a multimaster environment, where regular transaction origin and replica behavior are required on a per session level concurrently. To achieve the required flexibility, we need to change the definition of the pg_trigger attribute tg_enabled. It currently is a boolean. I would like to change it into a char along with the syntax of ALTER TRIGGER. The value definitions of tg_enabled would be A fires always N fires never O fires on transaction origin only R fires on replica only Anyone preferences how to map that to ALTER TRIGGER? A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. Likewise the system catalog pg_rewrite is extended with an attribute ev_enabled. It will have the same possible values and a new command, ALTER RULE, will match the functionality of ALTER TRIGGER. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: