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

From Andrew Dunstan
Subject Re: explain output infelicity in psql
Date
Msg-id 4B2035C3.4020703@dunslane.net
Whole thread Raw
In response to Re: explain output infelicity in psql  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: explain output infelicity in psql  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

Robert Haas wrote:
> On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>   
>> I have just noticed while checking the EXPLAIN YAML patch that the non-text
>> explain formats are output as a single line with embedded line feeds, while
>> the text format is delivered as a set of text records, one per line. The
>> practical effect of this is that psql decorates the non-text format output
>> with continuation characters:
>>
>>     
[snip]
>> Those + chars at the end of the line are ugly, to say the least, and they
>> make the supposedly machine-readable formats not so machine readable if
>> anyone wanted to c&p the output into a parser. (I'm mildly surprised this
>> hasn't been noticed before).
>>
>> Maybe we need to teach psql not to do this formatting for EXPLAIN output?
>>     
>
> 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.

cheers

andrew


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Adding support for SE-Linux security
Next
From: Tatsuo Ishii
Date:
Subject: Re: [PATCH] Windows x64 [repost]