Re: psql: Count all table footer lines in pager setup

Erik Wienhold <ewie@ewie.name> writes:
> On 2025-10-02 00:25 +0200, Tom Lane wrote:
>> I am not entirely sure that we should commit 0002 though; it may be
>> that the savings is down in the noise anyway once you consider all
>> the other work that happens while printing a big table.

> I see larger gains for queries that produce cells with many newlines,
> benchmarked with a variation of my test-psql-pager.py script from
> upthread. ...
> Based on that I think you should push v4-0002.

OK, we'll keep it.

As I was doing some desultory manual testing, I realized that v4
still has a notable gap: it fails to account for the "(n rows)"
default footer.  That's because that is not present in cont->footers
but is manually injected by footers_with_default, and count_table_rows
wasn't dealing with that.  It's a little more complicated than just
calling that function, because the various vertical modes don't use
the default footer.  After some code study I decided that we could
use the existing "expanded" flag to decide which footer definition
to apply, but I decided to rename it to "vertical" to reduce confusion
with the not-a-boolean cont->opt->expanded field.

Despite all this hackery, the count is still only really accurate
for the "\pset format aligned" modes.  I figure we can leave
tidying up the other modes for another day, because I doubt that
anybody cares about interactive output of, say, LaTeX format.
(Perhaps unaligned mode would be the first priority to tidy up.)

Another inaccuracy that I find mildly annoying now that we've got it
mostly right is that we are not accounting for the blank line that
psql likes to print after the query result, so that you can still
end with the first output line scrolled off your screen despite
non-use of the pager.  Not sure about a non-kluge way to count that,
though: it's outside the domain of print.c, and other callers might
not have a similar behavior.

I cleaned up the TAP test, too.  This version redirects PAGER
to "wc -l", so that it's very obvious from the output whether
or not the pager was used.

			regards, tom lane