From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: explain output infelicity in psql |
Date: | 2009-12-10 14:22:10 |
Message-ID: | 603c8f070912100622m55ad3db5j6515bd1f60cfecba@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-12-10 14:40:05 | Re: explain output infelicity in psql |
Previous Message | Robert Haas | 2009-12-10 14:19:26 | Re: EXPLAIN BUFFERS |