Re: [SPAM] Re: Proposed patch - psql wraps at window width

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Bryce Nesbitt" <bryce2(at)obviously(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Brendan Jurd" <direvus(at)gmail(dot)com>, <heikki(at)enterprisedb(dot)com>
Subject: Re: [SPAM] Re: Proposed patch - psql wraps at window width
Date: 2008-04-29 09:11:39
Message-ID: 87lk2x81pw.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Peter Eisentraut" <peter_e(at)gmx(dot)net> writes:

> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
>> We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> output.
>
> This is quite a useless complication. Readline uses exactly the same ioctl()
> call to determine the columns, so if ioctl() were to fail, then COLUMNS would
> be unset or wrong as well.

COLUMNS is just a regular environment variable. The user is free to set it and
many people have dotfiles, aliases, or scripts which do just that.

Consider, for example, someone with a cron job which runs several commands
such as "ls -C", "dpkg -l", and of course "psql -Pformat=wrapped" to generate
various reports and wants it all formatted to 72 columns. They would normally
just set COLUMNS=72 and run their commands and get an email all formatted to
72 columns.

But your point is valid, that's why I'm not too worried about cases where
COLUMNS is set to the desired width but readline interferes with it. In those
cases we would be using the ioctl value anyways. It would probably still be a
good idea to getenv(COLUMNS) early on before readline is initialized though.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message dv @ nabble 2008-04-29 09:40:53 Re: SRF in SFRM_ValuePerCall mode
Previous Message dv @ nabble 2008-04-29 09:06:58 Re: SRF in SFRM_ValuePerCall mode