Dmitri:
Thanks for the response.
I am resigned to just patch each major release with my own pile of hook
code that I can quickly
graft into the code base, currently grafting 9.2.0.
My strategy is to let the PG code base float around with all the work of
the fine hackers on this list,
maybe debate a couple of things with some friendly types, but
really just put my effort into logic piled into external replication
daemon which
will NOT change due to anything in the PG core.
If one day, the code base actually feeds me the event information I
need, maybe I will change it.
And I have not seen anybody request my hook code but a few have
responded that the are working
on things in the code base, release date unknown.
Cheers,
marco
On 9/24/2012 10:20 AM, Dimitri Fontaine wrote:
> "md@rpzdesign.com" <md@rpzdesign.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,