Re: explain output infelicity in psql - Mailing list pgsql-hackers

From Robert Haas
Subject Re: explain output infelicity in psql
Date
Msg-id 603c8f070912101902p45a03d97o64ab6da973f63bda@mail.gmail.com
Whole thread Raw
In response to Re: explain output infelicity in psql  (Bruce Momjian <bruce@momjian.us>)
Responses Re: explain output infelicity in psql
Re: explain output infelicity in psql
List pgsql-hackers
On Thu, Dec 10, 2009 at 8:11 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Andrew Dunstan wrote:
>>
>>
>> Tom Lane wrote:
>> > 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.
>> >
>> >
>> >
>>
>> If we really want to make linefeeds visible, I think we should place the
>> indicators immediately after the character preceding the line feed, not
>> next to the column separator.
>
> One idea would be to change the column _separator_ for newlines --- that
> way, they don't show up for single-column output.

Hilariously enough, that's exactly what we used to do.  I am leaning
toward the view that we should revert all the ASCII output format
changes vs. 8.4 and let people use the new unicode mode if they want
all the spiffy bells and whistles.

...Robert


pgsql-hackers by date:

Previous
From: Takahiro Itagaki
Date:
Subject: Re: YAML Was: CommitFest status/management
Next
From: KaiGai Kohei
Date:
Subject: Re: Largeobject Access Controls (r2460)