Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > Peter Eisentraut wrote:
> > > > 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.
> > >
> > > I was thinking about Win32 or binaries that don't have readline.
> > 
> > These rules don't seem very consistent.  You are mixing platform 
> > dependencies, 
> > build options, theoretical, unproven failures of kernel calls, none of 
> > which 
> > have anything to do with each other.  For example, if readline weren't 
> > installed, then there would be no one who sets COLUMNS, so why look at it?  
> > If you want to allow users to set COLUMNS manually (possibly useful, see 
> > Greg 
> > Stark's arguments), then it should have priority over ioctl(), not the 
> > other 
> > way around.
> 
> OK, two people like it, no one has objected.  :-)  I will work on making
> those changes.  Thanks.

OK, so COLUMNS should take precedence.  I assume this is going to
require us to read the COLUMNS enviroment variable in psql _before_
readline sets it, and that COLUMNS will only affect screen output, like
ioctl().  Is that consistent?

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to