Re: Command Triggers

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Command Triggers
Date: 2011-12-19 14:31:17
Message-ID: 4EEF4AB5.6030902@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/18/2011 09:02 PM, Robert Haas wrote:
> If we're actually going to expose the parse tree, I think JSON
> (or even XML) would be a far better way to expose that than the
> existing nodeToString() output. Sure, you could make due with the
> nodeToString() output for some things, especially in PL/perl or
> PL/python. But JSON would be far better, since it's a standard format
> rather than something we just made up, and could be used in PL/pgsql
> as well, given proper support functions.

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). We're going in a direction I don't think is very well explored
yet, by anyone. The idea that we're going to learn enough to accumulate
a comprehensive, stable API before release is rather optimistic.
There's something to be said for Dimitri's suggested approach from the
perspective of "ship it knowing it works for features A, B, then let's
see what else the users think to do with it". We can't determine what
feature complete looks like from what other people are doing anymore;
only way to find out is to see what the world at large thinks of after
release.

Think of it as being like the EXPLAIN plan output. That shipped as just
text, programs popped up to parse it anyway, they suffered some breaks
with each new release. That was still a major win. Then, new easier to
parse formats appeared, making the bar to entry for writing new such
tool much lower. And the construction of a better API for output
benefited from seeing what people had actually been struggling with
before then.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-12-19 14:33:22 Re: Page Checksums
Previous Message Stephen Frost 2011-12-19 14:18:21 Re: Page Checksums