pgsql-server/src backend/access/common/printtu ...
От | tgl@postgresql.org (Tom Lane) |
---|---|
Тема | pgsql-server/src backend/access/common/printtu ... |
Дата | |
Msg-id | 20030506202628.41F84475CBC@postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
CVSROOT: /cvsroot Module name: pgsql-server Changes by: tgl@postgresql.org 03/05/06 16:26:28 Modified files: src/backend/access/common: printtup.c src/backend/commands: explain.c portalcmds.c prepare.c schemacmds.c src/backend/executor: execMain.c execTuples.c functions.c spi.c tstoreReceiver.c src/backend/tcop: dest.c postgres.c pquery.c utility.c src/backend/utils/misc: guc.c src/backend/utils/mmgr: portalmem.c src/include/access: printtup.h src/include/commands: explain.h portalcmds.h prepare.h src/include/executor: execdesc.h executor.h tstoreReceiver.h src/include/tcop: dest.h pquery.h utility.h src/include/utils: guc.h portal.h Log message: Restructure command destination handling so that we pass around DestReceiver pointers instead of just CommandDest values. The DestReceiver is made at the point where the destination is selected, rather than deep inside the executor. This cleans up the original kluge implementation of tstoreReceiver.c, and makes it easy to support retrieving results from utility statements inside portals. Thus, you can now do fun things like Bind and Execute a FETCH or EXPLAIN command, and it'll all work as expected (e.g., you can Describe the portal, or use Execute's count parameter to suspend the output partway through). Implementation involves stuffing the utility command's output into a Tuplestore, which would be kind of annoying for huge output sets, but should be quite acceptable for typical uses of utility commands.
В списке pgsql-committers по дате отправления: