From: Robert Haas on 10 Dec 2009 12:08 On Thu, Dec 10, 2009 at 11:44 AM, Ron Mayer <rm_pg(a)cheapcomplexdevices.com> 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? I don't think inconsistency is a good thing here. Apparently the old format is available via \pset linestyle old-ascii. We can either decide that people should use that format if they want that behavior, or we can decide that changing the default was a mistake and revert it. I don't think a half-way-in-between solution is a good option. ....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: "Kevin Grittner" on 10 Dec 2009 12:10 Robert Haas <robertmhaas(a)gmail.com> wrote: > Andrew Dunstan <andrew(a)dunslane.net> wrote: >> 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' > 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. Agreed. This would be a significant annoyance for me on a regular basis. If I can't turn it off, it would probably cause me to create my own locally patched version of psql. Another alternative would be to use some other tool to run queries where I wanted long values without this, but psql has so many nice features that I'd be switching back and forth, so the patch would probably be easier. -Kevin -- 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: Tom Lane on 10 Dec 2009 12:23 Andrew Dunstan <andrew(a)dunslane.net> writes: > 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. Yes it is. The real problem here is expecting the tabular format to be copy and pasteable, which is not a design goal it's ever had, and not one that we can start imposing on it at this late date. Why don't you just do "\pset format unaligned" (or "\a" if you're lazy)? regards, tom lane -- 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:43 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > >> 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. >> > > Yes it is. I don't see much virtue of having these characters when there is only one column. > The real problem here is expecting the tabular format to be > copy and pasteable, which is not a design goal it's ever had, and not > one that we can start imposing on it at this late date. Why don't you > just do "\pset format unaligned" (or "\a" if you're lazy)? > > > Well, I haven't had to up to now. I'm not sure what we have is exactly an advance. I guess I can set the linestyle to old-ascii in my .psqlrc, but having to do that all over the place is annoying. And clearly I'm not the only person who doesn't like this behaviour. 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: Tom Lane on 10 Dec 2009 12:55
Andrew Dunstan <andrew(a)dunslane.net> writes: > I don't see much virtue of having these characters when there is only > one column. So you can tell a newline in the data from a wrap due to line length. The need to be able to do that is not dependent on how many columns there are. > And clearly I'm not the only person who doesn't like this behaviour. It's just our usual negative reaction to any change whatsoever ;-). I was unimpressed with Leigh's changes too at the start, but I can see that there is value in it. I think that changing the behavior depending on how many columns there are is an incredibly ugly hack, and your assertions to the contrary aren't going to change my mind. If we think that this is such a bad idea it should be reverted, then let's revert it altogether. Another possibility, which I don't understand why it was dismissed so cavalierly, is to have EXPLAIN put out one row per logical line instead of using embedded newlines. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |