diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2002-02-27 19:36:13 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2002-02-27 19:36:13 +0000 |
| commit | 6779c55c228ba5904dc767a7882b47a2b4c74ff7 (patch) | |
| tree | 27a1df60ccf81098405bd477d653da6edebce6c0 /src/backend/utils/mmgr/portalmem.c | |
| parent | e22c9c44756da85bf1e453f83bf260c9e5ef5813 (diff) | |
| download | postgresql-6779c55c228ba5904dc767a7882b47a2b4c74ff7.tar.gz postgresql-6779c55c228ba5904dc767a7882b47a2b4c74ff7.zip | |
Clean up BeginCommand and related routines. BeginCommand and EndCommand
are now both invoked once per received SQL command (raw parsetree) from
pg_exec_query_string. BeginCommand is actually just an empty routine
at the moment --- all its former operations have been pushed into tuple
receiver setup routines in printtup.c. This makes for a clean distinction
between BeginCommand/EndCommand (once per command) and the tuple receiver
setup/teardown routines (once per ExecutorRun call), whereas the old code
was quite ad hoc. Along the way, clean up the calling conventions for
ExecutorRun a little bit.
Diffstat (limited to 'src/backend/utils/mmgr/portalmem.c')
| -rw-r--r-- | src/backend/utils/mmgr/portalmem.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/backend/utils/mmgr/portalmem.c b/src/backend/utils/mmgr/portalmem.c index 76827529224..7b04a0e036a 100644 --- a/src/backend/utils/mmgr/portalmem.c +++ b/src/backend/utils/mmgr/portalmem.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/utils/mmgr/portalmem.c,v 1.45 2002/02/14 15:24:09 tgl Exp $ + * $Header: /cvsroot/pgsql/src/backend/utils/mmgr/portalmem.c,v 1.46 2002/02/27 19:35:35 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -22,8 +22,8 @@ * sees a * fetch 1 from FOO * the system looks up the portal named "FOO" in the portal table, - * gets the planned query and then calls the executor with a feature of - * '(EXEC_FOR 1). The executor then runs the query and returns a single + * gets the planned query and then calls the executor with a count + * of 1. The executor then runs the query and returns a single * tuple. The problem is that we have to hold onto the state of the * portal query until we see a "close". This means we have to be * careful about memory management. |