Re: Command Triggers

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