Re: Better testing coverage and unified coding for plpgsql loops

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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