Hello! > 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. - can this macro become a function?
