Re: wrapping in extended mode doesn't work well with default pager - Mailing list pgsql-hackers

From Robert Haas
Subject Re: wrapping in extended mode doesn't work well with default pager
Date
Msg-id CA+TgmoaVugJKaZZj8AUoZC56dtuFMvGeNoMV2Nf_=waVZzteMg@mail.gmail.com
Whole thread Raw
In response to Re: wrapping in extended mode doesn't work well with default pager  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: wrapping in extended mode doesn't work well with default pager  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Wed, Jun 11, 2014 at 10:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Noah Misch <noah@leadboat.com> writes:
>> Based on the commit message and procedural history, I thought commit 6513633
>> was changing behavior solely for the combination of "\pset expanded" and
>> "\pset format wrapped".  Peter's and my test cases show that it also changed
>> behavior for "\pset expanded" alone.  That's a bug, unless someone sees to
>> argue that the new "\pset expanded" behavior is a desirable improvement in
>> spite of its origin as an accident.  Altering an entrenched psql output format
>> is a big deal.
>
> TBH I'm wondering if we shouldn't just revert that patch (and the
> subsequent fix attempts).  It was not a major feature and I'm thinking
> we have better things to do right now than try to fix the multiple
> logic holes it evidently has.  The author's certainly welcome to try
> again with a more carefully thought-through patch for 9.5.

So, it seems like we need to do something about this one way or
another.  Who's working on that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: review: Non-recursive processing of AND/OR lists
Next
From: Robert Haas
Date:
Subject: Re: Built-in support for a memory consumption ulimit?