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:
"m...@rpzdesign.com" <m...@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,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
