Re: Fix psql pager selection for wrapped expanded output

On 2026-07-01 09:14 +0200, Chao Li wrote:
> > On Jul 1, 2026, at 04:34, Erik Wienhold <ewie(at)ewie(dot)name> wrote:
> >
> > On 2026-06-12 12:01 +0200, Chao Li wrote:
> >> While testing “[27da1a796] Improve psql's ability to select pager mode
> >> accurately”, I found that the pager doesn’t work for expanded wrapped
> >> mode. However, I realized that this is not a new problem introduced by
> >> 27da1a796, it didn’t work before 27da1a796 either. Instead, with
> >> 27da1a796, we are almost there to make it work.
> >>
> >> 27da1a796 introduces a new helper count_table_lines(), that takes a
> >> per-column-width array. For expanded mode (vertical mode), all columns
> >> use the same data width. So we can simply build such a width_wrap
> >> array, and move IsPagerNeeded() to after dwidth is computed. Then the
> >> pager works in expanded wrapped mode.
> >>
> >> I tested with this procedure (making the terminal small with ~30 rows):
> >> ```
> >> \pset pager on
> >> \pset columns 25
> >> \pset expanded on
> >> \pset format wrapped
> >> select g AS id, 'name_' || g AS name, repeat('x', g * 5) AS payload from generate_series(1, 10) AS g;
> >> ```
> >> See the attached patch for details. I’m not going to add this to the
> >> v19 open items, as it’s not a v19-new bug.
> >
> > The changes to print.c look good to me and it works in manual testing.
>
> Thanks for your review and test.
>
> >
> >> +# With the 80-column pty, the payload wraps to two lines per row.
> >> +# Expanded output also prints one record header per row, plus a trailing
> >> +# blank line, so this produces 11 * 3 + 1 = 34 lines.
> >> +do_command(
> >> + "\\pset expanded on\n\\pset format wrapped\n\\pset columns 80\nSELECT repeat('x',138) AS payload FROM generate_series(1,11);\n",
> >
> > We can do without \pset columns 80 here since the PTY is already set to
> > 80 columns by the test setup on line 82. I'd also change the query to
> > return repeat('x', 80) which is sufficiently long for the wrapping to
> > occur. It's then also clear that this length is related to the PTY
> > width while 138 lacks any meaning IMO.
>
> Agreed and addressed in v2.

Thanks! LGTM.

--
Erik Wienhold