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: Robert Haas <robertmhaas@gmail.com>, Darafei Komяpa Praliaskouski <me@komzpa.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-01-03T19:37:02Z
Lists: pgsql-hackers
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
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