Andres Freund <andres@anarazel.de> writes:
>> If you target C coded triggers then all you need to do is provide a
>> pointer to the Node *parsetree, I would think. What else?
> Yes.
>
> Being able to turn that into a statement again is still valuable imo.
That part of the WIP code is still in the patch, yes.
>> The drawback though is still the same, the day you do that you've
>> proposed a public API and changing the parsetree stops being internal
>> refactoring.
> Yes, sure. I don't particularly care though actually. Changing some generic
> guts of trigger functions is not really that much of a problem compared to the
> other stuff involoved in a version migration.
Let's hear about it from Tom, who's mainly been against publishing that.
> The point is that with CREATE COMMAND TRIGGER only the internal part of the
> triggers need to change. No the external interface. Which is a big difference
> from my pov.
I'm not sure. The way you get the arguments would stay rather stable,
but the parsetree would change at each release: that's not a long term
API here. I fail to see much difference in between a hook and a command
trigger as soon as you've chosen to implement the feature in C.
> Also hooks are relatively hard to stack, i.e. its hard to use them sensibly
> from multiple independent projects. They also cannot be purely installed via
> extensions/sql.
That remains true, you can't easily know in which order your hooks will
get fired, contrary to triggers, and you can't even list the hooks.
I fear that we won't be able to answer your need here in 9.2 though.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
