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

On May 26, 2009, at 8:46 AM, Greg Stark <greg.stark@enterprisedb.com>  
wrote:

> 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.

Your check is in the mail, too.

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

I was thinking about that, too, so +1.

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

I think that's probably over-complicated, but that's just MHO.

...Robert

>
>
> -- 
> 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