Re: explain output infelicity in psql - Mailing list pgsql-hackers

From Robert Haas
Subject Re: explain output infelicity in psql
Date
Msg-id 603c8f070912100622m55ad3db5j6515bd1f60cfecba@mail.gmail.com
Whole thread Raw
In response to Re: explain output infelicity in psql  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: explain output infelicity in psql  (Andrew Dunstan <andrew@dunslane.net>)
Re: explain output infelicity in psql  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Oh, dear.  I think that line continuation syntax was recently added -
>> subsequent to the machine-readable EXPLAIN patch.  The reason why it's
>> coded to emit everything as a single row is because that will be most
>> convenient for programs that are sucking down this data
>> programatically.  Otherwise, they'll have to concatenate all the lines
>> that are returned.
>>
>> And in fact for XML format, it's even worse: the data is returned as
>> type xml, but that obviously won't fly if we return each line as a
>> separate tuple.
>>
>> On first blush, I'm inclined to suggest that the addition of + signs
>> to mark continuation lines is a misfeature.
>
> I certainly agree we don't want to break up the non-text formats.
>
> A simple if ugly hack would make psql use old-ascii print style (which
> doesn't use these contionuation chars) if the first attribute in the
> resultset was named 'QUERY PLAN'
>
> If someone has a better suggestion I'm all ears.

I don't believe that machine-readable EXPLAIN output is the only
multi-line output value that anyone would ever wish to cut and paste
into an editor without picking up a lot of stray garbage, so I don't
think this is a solution.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: EXPLAIN BUFFERS
Next
From: Andrew Dunstan
Date:
Subject: Re: explain output infelicity in psql