From: Andrew Dunstan on 10 Dec 2009 08:41 Roger Leigh wrote: > On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote: > >> Robert Haas escribi�: >> >> >>> On first blush, I'm inclined to suggest that the addition of + signs >>> to mark continuation lines is a misfeature. >>> >> -1 >> >> EXPLAIN is a special case. IMHO it should be dealt with accordingly. >> > > If the formatting code can be taught that it's outputting for explain, > we can skip the wrap/newline markup easily. I don't think we > necessarily need to fall back to the old-ascii format, we just > conditionally disable that specific part. > > Alternatively, would it make more sense just to add a boolean pset > parameter to enable/disable the use of wrap/newline marks? It may > be that people may wish to disable it for use cases in addition > to EXPLAIN. > > > > We have already added a lot of knobs to twist, and I don't want to add any more. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 10 Dec 2009 09:22 On Wed, Dec 9, 2009 at 6:41 PM, Andrew Dunstan <andrew(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 10 Dec 2009 09:40 Robert Haas wrote: > 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. > > > Well, yes, another example that has just occurred to me is pg_proc.prosrc. So maybe this really is a misfeature. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Ron Mayer on 10 Dec 2009 11:44 Alvaro Herrera wrote: > Robert Haas escribi�: >> On first blush, I'm inclined to suggest that the addition of + signs >> to mark continuation lines is a misfeature. > > EXPLAIN is a special case. IMHO it should be dealt with accordingly. > Is it? Wouldn't it affect anyone who stuck XML in a txt column and wanted to copy and paste it into a parser? Perhaps single column output usually won't want the + signs (because it's copy&pasteable) but multi-column output could? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 10 Dec 2009 12:07
Ron Mayer wrote: > Alvaro Herrera wrote: > >> Robert Haas escribi�: >> >>> On first blush, I'm inclined to suggest that the addition of + signs >>> to mark continuation lines is a misfeature. >>> >> EXPLAIN is a special case. IMHO it should be dealt with accordingly. >> >> > > Is it? > > Wouldn't it affect anyone who stuck XML in a txt column and wanted > to copy and paste it into a parser? > > Perhaps single column output usually won't want the + signs (because > it's copy&pasteable) but multi-column output could? > Yeah, I'm thinking we should probably suppress output of format.nl_right (no matter what the format) where there is only one column. (This is even uglier with unicode linestyle, btw). That's a sane rule and it's not an ugly hack. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |