Re: [HACKERS] psql: Activate pager only for height, not width - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: [HACKERS] psql: Activate pager only for height, not width
Date
Msg-id CADxJZo3QirfNtK8P7VS9yBg2Tv0H0Gi2_V5+n3j=s1vDOAFsuQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] psql: Activate pager only for height, not width  (Christoph Berg <myon@debian.org>)
List pgsql-hackers
On Tue, 30 May 2017 at 05:30 Christoph Berg <myon@debian.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

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Broken hint bits (freeze)
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests