Re: Proposed patch - psql wraps at window width

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Proposed patch - psql wraps at window width
Дата
Msg-id 873apb8bs1.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Proposed patch - psql wraps at window width  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Proposed patch - psql wraps at window width  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Index AM change proposals, redux
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Is this TODO item done?