Revert my bad decision of about a year ago to make PortalDefineQuery
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Apr 2008 18:32:00 +0000 (18:32 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Apr 2008 18:32:00 +0000 (18:32 +0000)
commit7cb968202c4a9b692d0bcece71d9e8429ac52dc1
treeecf681381dc6c66606628f4066499c72e35fb81d
parent622cd5be24beb219e52d41fe2b652d6b1943c42a
Revert my bad decision of about a year ago to make PortalDefineQuery
responsible for copying the query string into the new Portal.  Such copying
is unnecessary in the common code path through exec_simple_query, and in
this case it can be enormously expensive because the string might contain
a large number of individual commands; we were copying the entire, long
string for each command, resulting in O(N^2) behavior for N commands.
(This is the cause of bug #4079.)  A second problem with it is that
PortalDefineQuery really can't risk error, because if it elog's before
having set up the Portal, we will leak the plancache refcount that the
caller is trying to hand off to the portal.  So go back to the design in
which the caller is responsible for making sure everything is copied into
the portal if necessary.
src/backend/commands/portalcmds.c
src/backend/commands/prepare.c
src/backend/executor/spi.c
src/backend/tcop/postgres.c
src/backend/utils/mmgr/portalmem.c