Re: [HACKERS] PL/pgSQL and SPI - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] PL/pgSQL and SPI
Date
Msg-id 36AF5E91.18DC8F3E@krs.ru
Whole thread Raw
In response to Re: [HACKERS] PL/pgSQL and SPI  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
Jan Wieck wrote:
> 
> >
> > Could we fill most of FunctionCache while parsing query ?!
> 
>     And  then  letting  copyNode()  copy  the  fcache too so it's
>     allocated in the same memory context.

Or we could move these items from fcache struct to
Func/Oper node...

>     Will require a flag in the fcache that is used to  tell  that
>     setFcache()  must  be  called to fill in the remaining fields
>     (there are some things taken from the actual executor state).
>     This  flag  is  then  cleared by copyNode() and the fields in
>     question left uncopied.

I missed here, please explain. What fields are you talking about?
Note that to support READ COMMITTED level I copy execution plan
_after_ execution started and so nothing used to keep execution
states, but not handled (re-initialized) by ExecInitNode, 
must be copied.
Also, see below.

>     This  might  also  let  us  get  rid  of  the  tree  copy  in
>     SPI_execp(),  if we form another tree-traversal function that
>     resets the flag in all Func and Oper nodes of the whole tree,
>     so the prepared/saved plan can be used directly.
> 
>     I'll give it a try some time.

Maybe. But note that if executor will try to use/pfree something
allocated in previous execution (in another memory context)
then we'll get trouble.

Vadim


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] regression test HAVING fixed
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] regression test HAVING fixed