explain output infelicity in psql
in [PgSql]
|
From: Robert Haas on 10 Dec 2009 12:57 On Thu, Dec 10, 2009 at 12:43 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > 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. I don't see much virtue in having these characters, period. The reason for having them is presumably to avoid confusion between two rows and one row with an embedded newline. If anything, this confusion is more likely with a single column than it is with multiple columns, since you don't have the context of the surrounding output. ....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 13:12 Tom Lane wrote: > 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. > If that's really what we want then I think we're doing a terrible job of it. Have a look at the output of: select E'xxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' as a, 1 as b; How do we know from that where the linefeeds are, exactly? 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 13:19 Andrew Dunstan <andrew(a)dunslane.net> writes: > Tom Lane wrote: >> 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. > If that's really what we want then I think we're doing a terrible job of > it. Have a look at the output of: > select > E'xxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' > as a, 1 as b; > How do we know from that where the linefeeds are, exactly? It works quite nicely for me ... in HEAD that is: regression=# select E'xxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' as a, 1 as b; a | b ------------------------------------------------------+--- xxxxxxx +| 1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | (1 row) regression=# The point here is exactly that previous versions didn't show the distinction well. 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: Ron Mayer on 10 Dec 2009 13:22 Tom Lane wrote: > Why don't you > just do "\pset format unaligned" (or "\a" if you're lazy)? That's fair. Now that I see it, I guess I should have been doing that for copy&paste work anyway. -- 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 14:07
Ron Mayer <rm_pg(a)cheapcomplexdevices.com> wrote: > Tom Lane wrote: >> Why don't you >> just do "\pset format unaligned" (or "\a" if you're lazy)? > > That's fair. Now that I see it, I guess I should have been > doing that for copy&paste work anyway. That'll cover my use cases. -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 |