Re: Command Triggers

On Mon, Dec 19, 2011 at 9:31 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> That seems pretty sensible; I wouldn't want to make it a hard requirement
> though.  There are three major ways this could go for 9.2:
>
> 1) Nothing is changed in core, the best that can be done is whatever you can
> cram into an extension.
>
> 2) 9.2 is released with Command Triggers using nodeToString() output as the
> detailed description.  That part is labeled "experimental and the API is
> expected to change completely in the next release"
>
> 3) 9.2 gets enough JSON support to also have an early nodeToJSON API
> instead.  Now it's labeled "early release and some API changes may be needed
> in future releases".
>
> From the perspective of enabling a developer community to spring up around
> working in this area, I don't see a huge difference between (2) and (3).

I do. Anyone coding in PL/pgsql is going to find the nodeToString()
output unusable, and we can easily provide a built-in JSON datatype
with enough richness to make that problem go away in time for 9.2.
People in PL/python and PL/perl may be a bit better off, but I see no
reason to ship something for 9.2 and then break it for 9.3 when we
could perfectly well make that compatibility break before the release.
(And, in case it's not clear, yes, I am volunteering to do the work,
if it comes down to that.)

But before we get bogged down in the data representation, I think we
need to make a more fundamental decision: to what extent are we OK
with exporting the parse tree at all, in any form? Tom is arguing
that we shouldn't, and I see his point: the recent DROP command rework
would have broken everybody's command triggers if we had adopted this
proposal, and that would be a real shame, because I don't particularly
like the idea that we can't continue to improve the code and refactor
things because someone out there might be depending on an older and
less well-considered behavior.

On the flip side, I don't really see any other way to make this
feature work at all. I think that AFTER CREATE triggers and BEFORE
DROP triggers could potentially be implemented by just passing OIDs
in, and that might be useful enough for many people. But what about
ALTER? I don't see that you're going to be able to write any sort of
meaningful triggers around ALTER without passing at least some of the
parse tree information to the trigger function.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company