Re: Counting lines correctly in psql help displays

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Counting lines correctly in psql help displays
Date: 2015-09-05 18:01:52
Message-ID: CAM-w4HNv2pajLzOMVBms05+D2bSGm=gDpZHEv6P3y7Lb0hjg3g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 5, 2015 at 5:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ordinarily I might think that was overkill, but given the number of times
> that we've failed to update those counts in the past, I think this is
> definitely a worthwhile investment in maintainability.

So to preface this, this was just a silly hack that turned out to be
more effective and simpler to code than I expected. But I suspect it's
still just a silly idea and easier to do what you suggested. Also, it
seems we often get the count wrong on SQL output and elsewhere anyways
and I'm not sure we really want to make that a strict rule. Also, as
someone who doesn't really like the whole "sometimes you get a pager
sometimes you don't" thing and turns it off whenever he sees it I'm
not in the best place to judge how much work it's worth to get the
line count right.

But that said, here's a tricksy patch that triggers an assertion
failure if the expected_lines is wrong. I intended it to trigger in
the regression tests so it only checks if the pager is actually off.
It wouldn't be hard to make it always check though.

--
greg

Attachment Content-Type Size
psql-assert-newlines.diff text/plain 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2015-09-05 18:12:36 Re: Allow a per-tablespace effective_io_concurrency setting
Previous Message Tomas Vondra 2015-09-05 17:17:41 Re: PATCH: index-only scans with partial indexes