From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Darafei Komяpa Praliaskouski <me@komzpa.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Better testing coverage and unified coding for plpgsql loops
Date: Wed, 03 Jan 2018 14:37:02 -0500
Message-ID: <22954.1515008222@sss.pgh.pa.us> (raw)
In-Reply-To: <20180103193144.ccc4bwcymxlznqol@alvherre.pgsql>
References: <20180103193144.ccc4bwcymxlznqol@alvherre.pgsql>
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 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 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.
I'm not sure whether inlining the function can be relied on to get rid
of the side effects of taking rc's address. It wouldn't take all that
much work to establish the point, probably, but it's work I don't care
to put into it.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, me@komzpa.net, pgsql-hackers@lists.postgresql.org
Subject: Re: Better testing coverage and unified coding for plpgsql loops
In-Reply-To: <22954.1515008222@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox