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
-
Merge coding of return/exit/continue cases in plpgsql's loop statements.
- 3e724aac74e8 11.0 landed
-
Improve regression tests' code coverage for plpgsql control structures.
- dd2243f2ade4 11.0 landed