Date: Wed, 3 Jan 2018 16:31:44 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Darafei =?utf-8?Q?Kom=D1=8Fpa?= Praliaskouski <me@komzpa.net>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Better testing coverage and unified coding for plpgsql loops
Message-ID: <20180103193144.ccc4bwcymxlznqol@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20911.1515005602@sss.pgh.pa.us>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

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