Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> However, while I was doing that, it seemed like the tests I was adding
>> were mighty repetitive, as many of them were just exactly the same thing
>> adjusted for a different kind of loop statement. And so I began to wonder
>> why it was that we had five copies of the RC_FOO management logic, no two
>> quite alike. If we only had *one* copy then it would not seem necessary
>> to have such duplicative test cases for it. A bit of hacking later, and
>> I had the management logic expressed as a macro, with only one copy for
>> all five kinds of loop.
> I'm not entirely sure about this rationale. Improving coverage is of
> course an important goal, but it's not the only one: each documented
> construct and behavior should be tested also explicitly, to avoid any
> inadvertant breakage. You're probably the most careful committer in the
> project, but what that means is that some other less careful committer
> (present or future) will need to hack this code again in the future and
> break some of the cases that you've made to work, because the test cases
> only exercise the generic behavior through some specific kind of loop,
> and not every individual kind of loop specifically.
I don't especially buy this argument, at least not in this case.
I can certainly believe that somebody would add another looping construct
to plpgsql in future, but with the new setup they'd just copy-and-paste
a macro invocation, and there's basically nothing to break. Fooling
with the RC logic itself is so rare as to be negligible --- looking at
the git history, most of it sprang full grown from Jan Wieck's forehead
in 1998, and the only meaningful change since then was when Neil Conway
added CONTINUE in 2005. So I think you're proposing to add regression
testing overhead that will burden every developer, every day, for the
foreseeable future, for a really negligible return. That path leads to
regression tests that nobody runs because they take two hours.
regards, tom lane