Re: Command Triggers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

Oh, you mean like exposing the parser for syntax coloring etc. I failed
to see it's the same case. Do we have an acceptable proposal on that
front yet?

> 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.

Could we offer people a sane API?

Another way could be to bypass BEFORE triggers and let people look at
the catalogs in the AFTER command trigger, and give them the object oid,
name and schemaname for them to do their lookups.

You can still RAISE EXCEPTION in an AFTER command trigger to cancel the
command execution, what you can not do anymore is canceling the command
without killing the current transaction.

> 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.

What do you think of removing the parsetree and the BEFORE trigger
support (so that trigger function can query the catalogs)?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support