Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
