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