Re: Better testing coverage and unified coding for plpgsql loops
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Darafei Komяpa Praliaskouski <me@komzpa.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-01-03T18:56:23Z
Lists: pgsql-hackers
On Wed, Jan 3, 2018 at 1:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I thought about this a bit harder and realized that if we make it > a function, we will have to pass "rc" by reference since the function > needs to change it in some cases. That might have no impact if the > compiler is smart enough, but I expect on at least some compilers > it would end up forcing rc into memory with an attendant speed hit. > > 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'm not prepared > to just assume that, especially not after the work I just did on > plpgsql record processing --- I initially thought that an extra > function call or three wouldn't matter in those code paths either, > but I found out differently. OK. I'm not really exercised about it, so I'll leave it to others to decide whether they want to spend time on it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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