Re: explain output infelicity in psql
От | Robert Haas |
---|---|
Тема | Re: explain output infelicity in psql |
Дата | |
Msg-id | 603c8f070912100622m55ad3db5j6515bd1f60cfecba@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: explain output infelicity in psql (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: explain output infelicity in psql
Re: explain output infelicity in psql |
Список | 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 по дате отправления: