On Mon, May 25, 2009 at 11:22:24AM -0400, Tom Lane wrote:
> Joshua Tolley <eggyknap@gmail.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.
Yeah, that's been bugging me, despite my recent support of that plan.
> 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.
Good point. The reason, as I remember it, that we wanted to be able to specify
what fields are returned was so that fields that are expensive to calculate
are calculated only when the user wants them. If that's the only
consideration, perhaps we should have a standard version and a "FULL" version,
e.g.
EXPLAIN [ANALYZE] [FULL] <query>
...where FULL would indicate the user wanted the all available statistics, not
just the cheap ones. Somewhere in there we'd also need an indicator to say we
wanted an output format other than the usual text version (such as the "WITH
XML" clause I think someone suggested); I maintain it's all just a table of
data, and should be represented the same way we represent any other table of
data.
- Josh / eggyknap