Jim Nasby <jim.na...@bluetreble.com> writes:
> On 9/5/15 3:50 PM, Tom Lane wrote:
>> Greg Stark <st...@mit.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
