Re: plpgsql leaking memory when stringifying datums

I wrote:
> BTW, it occurs to me to wonder whether we need to worry about such
> subsidiary leaks in type input functions as well.

Sure enough, once you find an input function that leaks memory, there's
trouble:

create type myrow as (f1 text, f2 text, f3 text);

create or replace function leak_assign() returns void as $$
declare
t myrow[];
i int;
begin
for i in 1..10000000 loop
t := '{"(abcd,efg' || ',hij)", "(a,b,c)"}';
end loop;
end;
$$ language plpgsql;

So the attached third try also moves the input function calls in
exec_cast_value into the short-lived context, and rejiggers callers as
necessary to deal with that. This actually ends up simpler and probably
faster than the original coding, because we are able to get rid of some
ad-hoc data copying and pfree'ing, and most of the performance-critical
code paths already had exec_eval_cleanup calls anyway.

Also, you wrote:
>> With that I was still left with a leak in the typecast() test function
>> and it turns out that sticking a exec_eval_cleanup into exec_move_row
>> fixed it. The regression tests pass, but I'm not 100% sure if it's
>> actually safe.

After some study I felt pretty nervous about that too. It's safe enough
with the statement-level callers of exec_move_row, but there are several
calls from exec_assign_value, whose API contract says specifically that
it *won't* call exec_eval_cleanup. Even if it works today, that's a bug
waiting to happen. So I took the exec_eval_cleanup back out of
exec_move_row, and instead made all the statement-level callers do it.

I think this version is ready to go, so barring objections I'll set to
work on back-patching it.

regards, tom lane