Hiroshi Inoue wrote:
>
> Hello all,
>
> It seems that SPI_prepare() doesn't work well in some cases.
>
> Pawel Pierscionek [pawel@astercity.net] reported about the
> following case 1([SQL] drop table in pgsql).
> Michael Contzen [mcontzen@dohle.com] reported about the
> following case 2(PL/PGSQL bug using aggregates).
> You can find it from pgsql-hackers archive.
>
> 1. PL/pgSQL can't execute UTILITY commands.
> SPI_prepare() doesn't copy(save) the utilityStmt member of
> Query type nodes,because copyObject() is not implemented
> for nodes of (Create/Destroy etc)Stmt type.
Thank's for that. I wondered why PL/pgSQL wasn't able to
execute utility statements. Unfortunately I wasn't able to
track it down the last days, because I had trouble with my
shared libraries (glibc6 and libstdc++ aren't easy-going on
Linux :-).
Knowing where the problem is located saves me a lot of time.
>
> 2. Aggregates in PL/pgSQL cause wrong results.
>
> Is it proper to use set_agg_tlist_references() function to
> reconstruct aggs member node for Agg type nodes ?
Don't know. It is important, that the copy of the tree has
absolutely NO references to anything outside itself. The
parser/rewrite/planner combo creates all plans in the actual
transactions memory context. So they will get destroyed at
transaction end.
SPI_saveplan() simply copies it into another memory context
that lives until the backend dies. It uses the node copy
function for this, so the result of that should be a totally
independed, self referencing tree that can stand alone.
I think that copyObject() should produce an ERROR if there
are nodes it cannot handle correctly (like queries for
utilities). This would prevent the backend crashes from
trying to invoke utilities inside procedural languages.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
