Re: generic options for explain

Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without disturbing
the application i.e. while still returning the regular result set.

But I also like being able to conveniently run explain and get the
results formatted to fit on the screen in a single step. I don't see
anything wrong with Robert's direction to pass options to explain. It
doesn't solve every problem but it doesn't make any of the other
things we need harder either.

On a bike-shedding note I would rather have the rhs of the option be
optional and default to true for boolean options.

Actually if we make a set of explain_* guc options we could make the
options just locally set those options.

--
Greg

On 26 May 2009, at 13:15, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> On Monday 25 May 2009 18:02:53 Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> This is all much more complicated than what I proposed, and I fail
>>> to
>>> see what it buys us. I'd say that you're just reinforcing the
>>> point I
>>> made upthread, which is that insisting that XML is the only way to
>>> get
>>> more detailed information will just create a cottage industry of
>>> beating that XML output format into submission.
>>
>> The impression I have is that (to misquote Churchill) XML is the
>> worst
>> option available, except for all the others. We need something
>> that can
>> represent a fairly complex data structure, easily supports addition
>> or
>> removal of particular fields in the structure (including fields not
>> foreseen in the original design), is not hard for programs to parse,
>> and is widely supported --- ie, "not hard" includes "you don't have
>> to
>> write your own parser, in most languages". How many realistic
>> alternatives are there?
>
> I think we are going in the wrong direction. No one has said that
> they want a
> machine-readable EXPLAIN format. OK, there are historically about
> three
> people that want one, but they have already solved the problem of
> parsing the
> current format. And without having writtens such a parser myself I
> think that
> the current format is not inherently hard to parse.
>
> What people really want is optional additional information in the
> human-
> readable format. Giving them a machine readable format does not
> solve the
> problem. Giving them a machine readable format with all-or-none of
> the
> optional information and saying "figure it out yourself" does not
> solve
> anything either. The same people who currently complain will
> continue to
> complain.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers