On Sun, Sep 14, 2014 at 09:15:30PM -0700, Peter Geoghegan wrote: > On Sun, Sep 14, 2014 at 9:05 PM, Tom Lane <[email protected]> wrote: > > More generally, though, it seems like the header comments in execTuples.c > > are not the best place to document global behavior ... > > > Yeah, my thoughts exactly.
I applied the attached patch to at least clean up the breakage. -- Bruce Momjian <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
diff --git a/src/backend/executor/execTuples.c b/src/backend/executor/execTuples.c new file mode 100644 index 66515f7..7f43441 *** a/src/backend/executor/execTuples.c --- b/src/backend/executor/execTuples.c *************** *** 70,83 **** * - ExecSeqScan() calls ExecStoreTuple() to take the result * tuple from ExecProject() and place it into the result tuple slot. * ! * - ExecutePlan() calls ExecSelect(), which passes the result slot ! * to printtup(), which uses slot_getallattrs() to extract the ! * individual Datums for printing. ! * ! * At ExecutorEnd() ! * ---------------- ! * - EndPlan() calls ExecResetTupleTable() to clean up any remaining ! * tuples left over from executing the query. * * The important thing to watch in the executor code is how pointers * to the slots containing tuples are passed instead of the tuples --- 70,76 ---- * - ExecSeqScan() calls ExecStoreTuple() to take the result * tuple from ExecProject() and place it into the result tuple slot. * ! * - ExecutePlan() calls the output function. * * The important thing to watch in the executor code is how pointers * to the slots containing tuples are passed instead of the tuples
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
