Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWoAL-0002md-Mq for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2018 18:53:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWoAL-0004p4-9t for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2018 18:53:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eWoAL-0004ov-3a for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2018 18:53:29 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eWoAI-0004zb-HU for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2018 18:53:28 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w03IrMZA020912; Wed, 3 Jan 2018 13:53:22 -0500 From: Tom Lane To: Robert Haas cc: Alvaro Herrera , =?UTF-8?Q?Darafei_Kom=D1=8Fpa_Praliaskouski?= , PostgreSQL Hackers Subject: Re: Better testing coverage and unified coding for plpgsql loops In-reply-to: References: <20180102134623.4mhrbnc2im6bfp7a@alvherre.pgsql> <31838.1514905690@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 03 Jan 2018 13:36:02 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20910.1515005602.1@sss.pgh.pa.us> Date: Wed, 03 Jan 2018 13:53:22 -0500 Message-ID: <20911.1515005602@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Tue, Jan 2, 2018 at 10:08 AM, Tom Lane wrote: >> It could be converted into a function returning bool, a la >> if (!loop_rc_processing(...)) >> break; > I prefer writing this sort of thing using a function call and > dispatching on the return value, as you suggest in the text quoted > here. Long macros that involve a zillion continuation lines are hard > to edit, and often hard to step through properly in a debugger. 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. regards, tom lane