From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Darafei =?utf-8?B?IktvbdGPcGEi?= Praliaskouski <me@komzpa.net>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Better testing coverage and unified coding for plpgsql loops
In-reply-to: <20180102134623.4mhrbnc2im6bfp7a@alvherre.pgsql>
References: <20180102134623.4mhrbnc2im6bfp7a@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 02 Jan 2018 10:46:23 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <31837.1514905690.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 02 Jan 2018 10:08:10 -0500
Message-ID: <31838.1514905690@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Darafei "Komяpa" Praliaskouski wrote:
>> - can this macro become a function?

> The "exit_action" argument makes it tough.  It can probably be done --
> it seems to require contorting the one callsite that uses "goto" though.

It could be converted into a function returning bool, a la

	if (!loop_rc_processing(...))
		break;

but then the burden is on you to show there's negligible performance
impact, a question that doesn't arise when just macro-izing existing
code.  I suppose the function could be made inline, but then we're
right back to the question of how well lcov will display the actual
code coverage.

			regards, tom lane