Re: generic options for explain - Mailing list pgsql-hackers

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@gmx.net> wrote:

> On Monday 25 May 2009 18:02:53 Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers