Re: Command Triggers

Hi,

On Monday, December 19, 2011 05:12:13 PM Robert Haas wrote:
> 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.)
I personally think youre underestimating the complexity of providing a
sensible json compatibility shim ontop the nodestring representation. But I
would like to be proven wrong ;)
Whats your idea?

> 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.
I don't see any realistic way to present the data in way thats abstracted from
the internals for now. The infrastructure is completely new and we don't
really know what it will be used for. I personally have no problem requiring
that any nontrivial nodestring access has to be done via c functions for now.
Building a completely new form of parstree seems way too much effort/flamebait
for me.

Andres