Re: generic options for explain

On Mon, May 25, 2009 at 11:22 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joshua Tolley <eggyknap(at)gmail(dot)com> writes:
>> I'm not sure I see why it would be less flexible. I'm imagining we define some
>> record type, and a function that returns a set of those records.
>
> I'm unimpressed by the various proposals to change EXPLAIN into a
> function. Quoting the command-to-explain is going to be a pain in the
> neck.

I agree with this, but there is a lot of sentiment (which I share)
that it should be possible to capture EXPLAIN output using subselect
or CTAS syntax, regardless of exactly what that output ends up being.
That seems to require that EXPLAIN be a fully-reserved keyword, so I
wonder what we think about that.

(The way I tested this quickly is to make '(' ExplainStmt ')' a third
production for select_with_parens. I'm not 100% sure that's the right
place for it, but a couple of other reasonable-looking places produced
non-obvious parsing conflicts.)

> And can you really imagine using it manually, especially if it
> returns so many fields that you *have to* write out the list of fields
> you actually want, else the result is unreadable?  It's going to be just
> as much of something you can only use through a helper application as
> the XML way would be.

Nothing could possibly be as bad as XML. I'm with Josh: if we produce
table-formatted output, someone can always turn it into XML or JSON or
whatever they want. The reverse figures to be a whole lot more
difficult.

...Robert