From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | "md\(at)rpzdesign(dot)com" <md(at)rpzdesign(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: External Replication |
Date: | 2012-09-24 16:20:25 |
Message-ID: | m2vcf3fl4m.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"md(at)rpzdesign(dot)com" <md(at)rpzdesign(dot)com> writes:
> You may want to consider changing the command TRIGGER into a command FILTER
> and possibly post processing TRIGGER that
> is determined to be called INSIDE the FILTER. Or some way to pass
> information between the FILTER and the post processing trigger.
The only current "event" supported by the system is the
"ddl_command_start" one. We mean to add some more, and triggers wanting
to communicate data in between "ddl_command_start" and "ddl_command_end"
(for example) will have to use something like a table.
> Also, something information as to whether a series of statements was ROLLED
> BACK would be helpful.
Event Triggers are not an autonomous transaction: any effect they have
in the database is rolled-backed when the main transaction is rolled
backed. You can use LISTEN/NOTIFY or PGQ that both know how to handle
that semantics.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Roberto Mello | 2012-09-24 16:22:25 | Re: pg_reorg in core? |
Previous Message | Tom Lane | 2012-09-24 15:44:36 | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |