Re: Better testing coverage and unified coding for plpgsql loops

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?