From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Counting lines correctly in psql help displays |
Date: | 2015-09-08 23:55:47 |
Message-ID: | 9061.1441756547@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> writes:
> On 9/5/15 3:50 PM, Tom Lane wrote:
>> Greg Stark <stark(at)mit(dot)edu> writes:
>>> But that said, here's a tricksy patch that triggers an assertion
>>> failure if the expected_lines is wrong.
>> Hmm ... that would put a premium on the linecount always being exactly
>> right (for all callers, not just the help functions). Not sure that
>> I want to buy into that --- it would require more complexity in the
>> callers than is there now, for sure.
> But only in an assert-enabled build. Surely there's enough other
> performance hits with asserts enabled that this wouldn't matter?
It's not about performance, it's about code complexity and maintenance
overhead. I'm looking to *reduce* the amount of personpower expended
on those line counts, not increase it; but adding an assertion requirement
that the counts be exactly right would require us to spend more development
effort on making them right.
> As for paging, ISTM the only people that would care are those with
> enormous terminal sizes would care, and assuming their pager is less
> simply adding -F to $LESS would get them their old behavior. So I think
> it's safe to just force paging.
Yeah, I'm leaning to just changing the counts to INT_MAX and being
done with it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-09-09 00:21:27 | Re: Improving test coverage of extensions with pg_dump |
Previous Message | Jim Nasby | 2015-09-08 23:41:58 | Re: Counting lines correctly in psql help displays |