Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eS58m-0002sd-5s for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Dec 2017 18:00:20 +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 1eS58l-00022z-N2 for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Dec 2017 18:00:19 +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 1eS58l-00022j-Gv for pgsql-hackers@lists.postgresql.org; Thu, 21 Dec 2017 18:00:19 +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 1eS58i-00054r-Hy for pgsql-hackers@lists.postgresql.org; Thu, 21 Dec 2017 18:00:18 +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 vBLI0COP030462; Thu, 21 Dec 2017 13:00:12 -0500 From: Tom Lane To: Robert Haas cc: Andres Freund , PostgreSQL Hackers Subject: Re: Letting plpgsql in on the fun with the new expression eval stuff In-reply-to: References: <32589.1513706441@sss.pgh.pa.us> <20171220135602.4ixfvaqpeb6z7dil@alap3.anarazel.de> <27674.1513789968@sss.pgh.pa.us> <20171220174243.n4y3hgzf7xd3mm5e@alap3.anarazel.de> <24880.1513793601@sss.pgh.pa.us> <27734.1513802658@sss.pgh.pa.us> <4249.1513811175@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 20 Dec 2017 22:58:26 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30460.1513879212.1@sss.pgh.pa.us> Date: Thu, 21 Dec 2017 13:00:12 -0500 Message-ID: <30461.1513879212@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Wed, Dec 20, 2017 at 6:06 PM, Tom Lane wrote: >> Anyway, I left it as-is, but I'm willing to make the change if >> people feel the other way is better. > I feel the other way -- let's not add more pointer indirections if it > isn't really necessary. OK --- with any luck, the changes in the paramFetch API will force people to update relevant code anyway. It would only be an issue for code that is not calling paramFetch at all, and such code is broken anyway for dynamic param lists. Pushed without touching that issue. regards, tom lane