Re: first cut at PL/PgSQL table functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: first cut at PL/PgSQL table functions
Date: 2002-08-20 16:07:34
Message-ID: 13409.1029859654@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> So how do we pass the mode info from the function back up the line to
> FunctionNext? Would it make sense to add a member to ExprContext?

Probably not, because the same ExprContext would be used for evaluation
of the function's arguments. If you have
select ... from foo(bar(22))
bar is not being called in a context that should accept a set result,
I think. Possibly this example says that we'd better change the way
nodeFunctionscan.c uses execQual.c --- instead of letting
ExecEvalExpression take the whole expression, just use it to evaluate
the function arguments, and then call the function directly from
nodeFunctionscan.c. (I have a vague recollection that you did it that
way originally and I encouraged you to use ExecEvalExpression instead;
looks like I was wrong...)

> Does a good primer on proper backend memory-context handling exist?

The original design document is in src/backend/utils/mmgr/README;
somebody needs to recast that into present tense and put it into the
Developer's Guide SGML docs.

If you read that and feel you understand it, next read
executor/nodeAgg.c and see if you follow the memory management there...
AFAIR that's the most complex use of short-term contexts in the system.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2002-08-20 16:13:03 Re: first cut at PL/PgSQL table functions
Previous Message Rod Taylor 2002-08-20 15:57:31 Correct regression tests