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 verified it still passes the previous set of tests and then removed the ones that seemed redundant, yielding plpgsql-unify-loop-rc-code.patch below. So what I propose actually committing is the combination of these two patches.
I have looked into plpgsql-unify-loop-rc-code.patch.
I have two questions:
- how do currently existing coverage tools display coverage for such a large macro?
I expect DEFINE's to be treated as comments.
I've looked into https://coverage.postgresql.org/src/port/qsort.c.gcov.html and on line 70 I see a similar multi line define that is yellow in coverage, not counted at all. I think that "higher coverage" effect you are seeing is mostly due to code being hidden from coverage counter, not actually better testing. Another thing I see is that most define's are in .h files, and they're also not in coverage report mostly.
