Re: Better testing coverage and unified coding for plpgsql loops

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It could be converted into a function returning bool, a la
>>     if (!loop_rc_processing(...))
>>         break;

> I prefer writing this sort of thing using a function call and
> dispatching on the return value, as you suggest in the text quoted
> here. Long macros that involve a zillion continuation lines are hard
> to edit, and often hard to step through properly in a debugger.

I thought about this a bit harder and realized that if we make it
a function, we will have to pass "rc" by reference since the function
needs to change it in some cases.  That might have no impact if the
compiler is smart enough, but I expect on at least some compilers
it would end up forcing rc into memory with an attendant speed hit.

I really think we should stick with the macro implementation, unless
somebody wants to do some actual investigation to prove that a
function implementation imposes negligible cost.  I'm not prepared
to just assume that, especially not after the work I just did on
plpgsql record processing --- I initially thought that an extra
function call or three wouldn't matter in those code paths either,
but I found out differently.

            regards, tom lane