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 |
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 |