Thanks to visit codestin.com
Credit goes to postgrespro.com

Re: first cut at PL/PgSQL table functions - Mailing list pgsql-patches

From Tom Lane
Subject Re: first cut at PL/PgSQL table functions
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: first cut at PL/PgSQL table functions  (Joe Conway <[email protected]>)
List pgsql-patches
Joe Conway <[email protected]> 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

pgsql-patches by date:

Previous
From: Rod Taylor
Date:
Subject: Correct regression tests
Next
From: Joe Conway
Date:
Subject: Re: first cut at PL/PgSQL table functions