Re: Proposed patch - psql wraps at window width - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Proposed patch - psql wraps at window width
Date
Msg-id 873apb8bs1.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Proposed patch - psql wraps at window width  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Proposed patch - psql wraps at window width  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
"Bruce Momjian" <bruce@momjian.us> writes:

> Uh, if you do that I am not sure what the user would want.  I duplicated
> what we do with PAGER and unless there is a clear mandate I think we
> should keep the wrapping detection consistent with that;  we have gotten
> no complaints.  Pager will not work for -o /dev/tty either.

I've explained before why I think the pager case is not analogous. In any case
a pager *can't* work if you do -o /dev/tty.

>> b) If you dump to a file it will still respect COLUMNS. This might be a bit
>>    weird since bash sets COLUMNS so your file width will be based on the size
>>    of your terminal. But people also do things like COLUMNS=120 psql -o f ...
>
> No, that will make the regression tests fail and it is hard to say why
> you would want a file wrap width to match your screen width.

Well you don't know where the pipe is going, it could be, for example, piped
to a pager.

I think the point is to keep the logic simple and not put in special cases
based on assumptions of what users might do. If you have simple logic which
doesn't do what the user expects in a corner case they understand and we can
tell them to override it with \pset. If you have logic which does what they
want normally but does something different sometimes based on criteria which
they consider irrelevant then they get angry.

> Your final change is to assume a width of 79 if no columns are detected.
> I also don't think that is a good idea, and if we want to do that we
> would need to discuss that too.

Well what width would you use if you have no better info?

> I don't want to over-design this.

I think your design is more complicated than mine. I've *removed* some of the
special cases from your logic. Mine is very straightforward: explicit user
setting takes precedence always, otherwise we try to use the ioctl and if that
fails fall back to COLUMNS.

Yours is "explicit setting takes precedence otherwise if you're on a terminal
and haven't redirected the output then ( we try the terminal if that fails
then we fall back to COLUMNS ) otherwise we ignore the ioctl and COLUMNS and
uh, I don't know what happens.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Index AM change proposals, redux
Next
From: Tom Lane
Date:
Subject: Re: Is this TODO item done?