Re: Proposed patch - psql wraps at window width

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bryce Nesbitt <bryce2(at)obviously(dot)com>, heikki(at)enterprisedb(dot)com
Subject: Re: Proposed patch - psql wraps at window width
Date: 2008-04-24 04:34:46
Message-ID: 200804240434.m3O4Ykg14302@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Gregory Stark wrote:
> "Bruce Momjian" <bruce(at)momjian(dot)us> writes:
>
> > Brendan Jurd wrote:
> >> To me, this message sounds like you're setting the width of a single
> >> column, when in fact you're setting the target *total* width of the
> >> table. I think this message would be more clear if it read "Target
> >> output width ..." or "Target table width ...". Also, as far as the
> >> user is concerned the format is referred to as "wrapped", not "wrap".
> >
> > Good point. I have updated the text to be:
> >
> > test=> \pset columns 70
> > Target width of file and pipe output for "wrap" format is 70.
>
> I think "file and pipe output" is short-sighted. There are lots more cases
> this is necessary including SSH sessions and emacs shell buffers, etc. And as
> I pointed out there are often cases where the user may want to override the
> terminal width in any case.
>
> Earlier I suggested -- and nobody refuted -- that we should follow the
> precedents of ls and man and other tools which need to find the terminal
> width: Explicitly set width takes precedence always, if it's not explicitly
> set then you use the ioctl, and if that fails then you use the COLUMNS
> environment variable.

Yes, I like that better. Patch updated, same URL:

ftp://momjian.us/pub/postgresql/mypatches/wrap

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kaloyan Iliev 2008-04-24 08:11:14 I think this is a BUG?
Previous Message Ron Mayer 2008-04-24 04:25:20 Re: Per-table random_page_cost for tables that we know are always cached

Browse pgsql-patches by date

  From Date Subject
Next Message Euler Taveira de Oliveira 2008-04-24 04:51:40 Re: lc_time and localized dates
Previous Message Gregory Stark 2008-04-24 03:27:23 Re: Proposed patch - psql wraps at window width