Re: Better testing coverage and unified coding for plpgsql loops

Tom Lane wrote:

> 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.

I don't really care too much about the macro-or-function side of this,
but if you wanted to improve debuggability avoiding the performance cost
of a function call, you could use a static inline function, which is
supposed (AFAIK) to have performance characteristics equivalent to those
of a macro. But again I'm not voting either way and I'm not in a
position to do the legwork either.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services