Re: explain output infelicity in psql

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: explain output infelicity in psql
Date: 2009-12-09 23:41:55
Message-ID: 4B2035C3.4020703@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Theo Schlossnagle 2009-12-10 00:08:07 Re: [patch] executor and slru dtrace probes
Previous Message Bruce Momjian 2009-12-09 22:38:38 Re: Adding support for SE-Linux security