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)
commitfee2634d914f5d31471c2f4f428304dd9c64f970
tree6055bc3bf47e9896b41a10ac1a01158698f130f5
parente0a83af855e52963aa932abd67aa263a0ad1773c
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