Re: Better testing coverage and unified coding for plpgsql loops - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Better testing coverage and unified coding for plpgsql loops
Date
Msg-id 20180103193144.ccc4bwcymxlznqol@alvherre.pgsql
Whole thread Raw
In response to Re: Better testing coverage and unified coding for plpgsql loops  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better testing coverage and unified coding for plpgsql loops
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: to_timestamp TZH and TZM format specifiers
Next
From: Vik Fearing
Date:
Subject: Re: to_timestamp TZH and TZM format specifiers