Horton

Re: Letting plpgsql in on the fun with the new expression eval stuff

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2017-12-21T18:00:12Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 20, 2017 at 6:06 PM, Tom Lane <tgl@sss.pgh.pa.us> 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

Commits

  1. Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.

  2. Further reduce overhead for passing plpgsql variables to the executor.