Re: psql: Activate pager only for height, not width

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: Activate pager only for height, not width
Date: 2017-06-23 02:47:32
Message-ID: CADxJZo3QirfNtK8P7VS9yBg2Tv0H0Gi2_V5+n3j=s1vDOAFsuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 30 May 2017 at 05:30 Christoph Berg <myon(at)debian(dot)org> wrote:

> Oh interesting, I didn't know about pager_min_lines. That sounds
> useful as well. +1 on the analogous pager_min_cols option.
>

On closer inspection, I note that psql already has a 'columns' \pset
option, which does control the width for triggering the pager, but also
controls the width for wrapping and auto-expanded mode purposes. So, I can
set 'columns' to get the pager behaviour that I want, but I also get
unwanted effects where I'd rather let the default (terminal width) apply.

So if we were to add a 'pager_min_cols', we'd have to decide how it
interacts with 'columns'. For example, to determine whether to trigger the
pager, we look for 'pager_min_cols' first, and if that is not set, then
fall back to 'columns'. For all other width purposes, 'columns' would
continue to apply as present.

However, my feeling is that this is becoming a bit too fiddly. If
'columns' did not already exist then 'pager_min_cols' would make more
sense, but as it does already exist, my preference is to leave 'columns'
as-is, and go for a height-only option to 'pager' instead.

Thoughts?

Cheers,
BJ

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-06-23 02:48:13 Re: intermittent failures in Cygwin from select_parallel tests
Previous Message Amit Kapila 2017-06-23 02:40:17 Re: Broken hint bits (freeze)