Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> We really need some higher-level API than the raw parse tree, and
>> I have to admit that I have no idea what that would look like.
>> But exposing parse trees to user-written triggers is a decision
>> that we will come to regret, probably as soon as the next release.
> I was under the illusion that providing users with ready to tweak
> examples of robust-against-changes code would cut it. I'd like the
> command triggers patch not to depend on designing this API we need.
Well, we don't have any such examples, because frankly the nodeToString
representation is pretty damn unfriendly. The only code we have that
does anything with it at all is the readfuncs.c code that turns it back
into trees of C structs, and that's no help for triggers not themselves
written in C. Besides which, readfuncs.c is the poster child for code
that does have to change every time we tweak the struct definitions.
We can't tell people to copy that approach.
> What do you think of removing the parsetree and the BEFORE trigger
> support (so that trigger function can query the catalogs)?
Well, it gets us out of the business of inventing a suitable API,
but I think it also reduces the feature to a point of near uselessness.
Essentially we'd be saying to trigger authors "something changed, feel
free to inspect the catalogs and see if you can guess what".
Just because the problem is hard doesn't mean you can get away with
not solving it.
regards, tom lane