Rethink plpgsql's way of handling SPI execution during an exception block.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 16 Nov 2004 18:10:16 +0000 (18:10 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 16 Nov 2004 18:10:16 +0000 (18:10 +0000)
commit7efa8411cc56383a9b7ac2203f310d0db81f0580
treea205f416cfee9d6c54864d06c72a2aa6f686f9e6
parent2bb3bcfcf9edb57d7bd3635b2201688defee6676
Rethink plpgsql's way of handling SPI execution during an exception block.
We don't really want to start a new SPI connection, just keep using the old
one; otherwise we have memory management problems as illustrated by
John Kennedy's bug report of today.  This requires a bit of a hack to
ensure the SPI stack state is properly restored, but then again what we
were doing before was a hack too, strictly speaking.  Add a regression
test to cover this case.
src/backend/executor/spi.c
src/include/executor/spi.h
src/pl/plpgsql/src/pl_exec.c
src/test/regress/expected/plpgsql.out
src/test/regress/sql/plpgsql.sql