Re: pgsql/ oc/src/sgml/func.sgml oc/src/sgml/relea ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/ oc/src/sgml/func.sgml oc/src/sgml/relea ...
Date: 2002-05-19 17:22:07
Message-ID: 29824.1021828927@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> Hmm. Have you tried this with recursive plpgsql functions? I have a
>> feeling that that little hack of replacing the flinfo link isn't gonna
>> work well in plpgsql, because of its caching of query plans.

> I don't understand what specific problem you are referring to.

After further thought I believe that the problem cannot occur until we
have plpgsql functions that can return sets (and even then it could be
worked around if exec_eval_simple_expr isn't used for functions
returning sets, which it probably couldn't be anyway).
ExecMakeFunctionResult only keeps call state in the plan tree for
set-valued functions, so the recursive re-use of the plan tree doesn't
matter otherwise.

Just chalk it up as another bit of messiness that we need to fix
someday.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Meskes 2002-05-19 20:00:53 pgsql/src/interfaces/ecpg ChangeLog preproc/ec ...
Previous Message Peter Eisentraut - PostgreSQL 2002-05-19 15:16:55 pgsql/src/backend/parser gram.y