On Friday, January 13, 2012 11:53:32 PM Dimitri Fontaine wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I personally think this is an error and those details should at least be
> > available on the c level (e.g. some pg_command_trigger_get_plan()
> > function, only available via C) to allow sensible playing around with
> > that knowledge. I don't really see making progress towards a nice
> > interface unless we get something to play around with out there.
>
> 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.
> 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.
> The way around this problem is that if you want a command
> trigger in C, just write an extension that implements the Process
> Utility hook.
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.
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.
Andres