CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: momjian@postgresql.org 03/03/27 11:51:29
Modified files:
contrib/tablefunc: tablefunc.c
doc/src/sgml : sql.sgml
doc/src/sgml/ref: copy.sgml declare.sgml fetch.sgml move.sgml
src/backend/access/transam: xact.c
src/backend/commands: copy.c portalcmds.c
src/backend/executor: Makefile execMain.c execQual.c nodeHash.c
nodeHashjoin.c nodeMaterial.c spi.c
src/backend/parser: analyze.c gram.y keywords.c
src/backend/storage/file: buffile.c fd.c
src/backend/tcop: dest.c
src/backend/utils/mmgr: mcxt.c portalmem.c
src/backend/utils/sort: logtape.c tuplestore.c
src/include/nodes: parsenodes.h
src/include/storage: buffile.h fd.h
src/include/tcop: dest.h
src/include/utils: portal.h tuplestore.h
src/pl/plpgsql/src: pl_exec.c
src/test/regress/expected: portals.out
src/test/regress/sql: portals.sql
Log message:
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
