Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> The main part of my answer, though, is that all the more complex use
> cases involving command triggers that Robert is offering are in fact
> possible to implement with what my patch is providing, as soon as you're
> ok with understanding the content and format of the nodeToString()
> output.
Hmm ... I don't think that I *am* ok with that. ISTM that we'd then
find ourselves with any changes in utility statement parse trees
amounting to a user-visible API break, and that's not an acceptable
situation.
We already have this issue of course with respect to C-code add-ons,
but (1) we've established an understanding that people should have to
recompile those for every major release, and (2) changes such as adding
a new field, or even changing an existing field that you don't care
about, don't break C source code. I don't know exactly what you're
imagining that user-written triggers would do with nodeToString strings,
but I'd bet a good lunch that people will use ad-hoc interpretation
methods that are not robust against changes at all. And then they'll
blame us when their triggers break --- not unreasonably, because we
failed to provide a sane API for them to use.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
