Re: Better testing coverage and unified coding for plpgsql loops

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Darafei "Komяpa" Praliaskouski <me@komzpa.net>, pgsql-hackers@lists.postgresql.org
Date: 2018-01-02T15:08:10Z
Lists: pgsql-hackers
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


Commits

  1. Merge coding of return/exit/continue cases in plpgsql's loop statements.

  2. Improve regression tests' code coverage for plpgsql control structures.