[PATCHES] trivial cleanup: ExecProcAppend
ExecProcAppend() wasn't called ExecAppend() because the latter name was
formerly used in execMain. Since that is no longer the case, this patch
renames ExecProcAppend() to ExecAppend() for the sake of consistency.
Barring any objection, I intend to apply this to HEAD within 24 hours.
-Neil
Index: src/backend/executor/execProcnode.c
===
RCS file: /home/neilc/private-cvsroot/pgsql-server/src/backend/executor/execProcnode.c,v
retrieving revision 1.44
diff -c -r1.44 execProcnode.c
*** src/backend/executor/execProcnode.c 29 Aug 2004 04:12:31 - 1.44
--- src/backend/executor/execProcnode.c 23 Sep 2004 07:37:58 -
***
*** 293,299
break;
case T_AppendState:
! result = ExecProcAppend((AppendState *) node);
break;
/*
--- 293,299
break;
case T_AppendState:
! result = ExecAppend((AppendState *) node);
break;
/*
Index: src/backend/executor/nodeAppend.c
===
RCS file: /home/neilc/private-cvsroot/pgsql-server/src/backend/executor/nodeAppend.c,v
retrieving revision 1.59
diff -c -r1.59 nodeAppend.c
*** src/backend/executor/nodeAppend.c 29 Aug 2004 04:12:31 - 1.59
--- src/backend/executor/nodeAppend.c 23 Sep 2004 07:37:58 -
***
*** 14,20
*/
/* INTERFACE ROUTINES
* ExecInitAppend - initialize the append node
! * ExecProcAppend - retrieve the next tuple from the node
* ExecEndAppend - shut down the append node
* ExecReScanAppend - rescan the append node
*
--- 14,20
*/
/* INTERFACE ROUTINES
* ExecInitAppend - initialize the append node
! * ExecAppend - retrieve the next tuple from the node
* ExecEndAppend - shut down the append node
* ExecReScanAppend - rescan the append node
*
***
*** 90,96
/*
* if scanning in reverse, we start at the last scan in the list
* and then proceed back to the first.. in any case we inform
! * ExecProcAppend that we are at the end of the line by returning
* FALSE
*/
appendstate-as_whichplan = appendstate-as_firstplan;
--- 90,96
/*
* if scanning in reverse, we start at the last scan in the list
* and then proceed back to the first.. in any case we inform
! * ExecAppend that we are at the end of the line by returning
* FALSE
*/
appendstate-as_whichplan = appendstate-as_firstplan;
***
*** 134,140
* (This is potentially wasteful, since the entire result of the
* append node may not be scanned, but this way all of the
* structures get allocated in the executor's top level memory
! * block instead of that of the call to ExecProcAppend.)
*
* Special case: during an EvalPlanQual recheck query of an inherited
* target relation, we only want to initialize and scan the single
--- 134,140
* (This is potentially wasteful, since the entire result of the
* append node may not be scanned, but this way all of the
* structures get allocated in the executor's top level memory
! * block instead of that of the call to ExecAppend.)
*
* Special case: during an EvalPlanQual recheck query of an inherited
* target relation, we only want to initialize and scan the single
***
*** 246,260
}
/*
! * ExecProcAppend
*
* Handles the iteration over the multiple scans.
- *
- * NOTE: Can't call this ExecAppend, that name is used in execMain.
*
*/
TupleTableSlot *
! ExecProcAppend(AppendState *node)
{
EState *estate;
int whichplan;
--- 246,258
}
/*
! * ExecAppend
*
* Handles the iteration over the multiple scans.
*
*/
TupleTableSlot *
! ExecAppend(AppendState *node)
{
EState *estate;
int whichplan;
***
*** 310,316
if (exec_append_initialize_next(node))
{
ExecSetSlotDescriptorIsNew(result_slot, true);
! return ExecProcAppend(node);
}
else
return ExecClearTuple(result_slot);
--- 308,314
if (exec_append_initialize_next(node))
{
ExecSetSlotDescriptorIsNew(result_slot, true);
! return ExecAppend(node);
}
else
return ExecClearTuple(result_slot);
Index: src/backend/po/cs.po
===
RCS file: /home/neilc/private-cvsroot/pgsql-server/src/backend/po/cs.po,v
retrieving revision 1.2
diff -c -r1.2 cs.po
*** src/backend/po/cs.po 19 Nov 2002 17:21:37 - 1.2
--- src/backend/po/cs.po 23 Sep 2004 07:38:03 -
***
*** 4961,4967
msgstr
#: ../executor/nodeAppend.c:293
! msgid ExecProcAppend:
Re: [PATCHES] doc patch for ssl in server
Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links at the bottom of the developer's page, http://developer.postgresql.org/index.php. --- Dominic Mitchell wrote: This patch attempts to note the use of the root.crt file in the server. Given that PostgreSQL will output a message complaining about it's absence if you're using SSL mode, I feel it's important that it gets a mention in the documentation at some point. -Dom [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] SSL Error Code logging.
Patch applied. Thanks. --- Dominic Mitchell wrote: This patch logs the error code in the default case, so that the user stands a chance of looking it up. Unrecognised error is always disheartening. :-) -Dom [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] psql: rollback only last query on error
Alvaro Herrera wrote: On Tue, Sep 21, 2004 at 02:30:17PM +0200, Michael Paesold wrote: http://archives.postgresql.org/pgsql-hackers/2004-09/msg00576.php One potential problem I see with the patch is that it opens lots of savepoints but does not release any. In this mode, given autocommit off (and even without that), there's potential for lots and lots of savepoints. Not sure how to fix that given that you shouldn't release user-specified savepoints ... Well, given that EXCEPTION blocks in Pl/pgSQL and the like also never release savepoints I think there will be more issues with savepoints in that area. Nevertheless, I have added a note to the documentation about the feature that warns of the possible consequences of those many savepoints. Also Tom Lane mentioned in another thread that even releasing savepoints does not really help because of the other resources used, e.g. for trx id locks, that can't be released at all till COMMIT. Also, you need to do something with \i. I think the global variable will be a less intrusive approach, at least while we are in beta. When 8.1 development starts, you can submit a patch to clean up. I have added a field to the pset settings to do that. Everything works now as I expected it to do. Using \i and psql file.sql the feature is disabled, otherwise it's controlled by the variable IMPLICIT_SAVEPOINTS and the transaction state (of course not useful when AUTOCOMMIT is on and no BEGIN issued). A final thing is the name for this option... I don't really like IMPLICIT_SAVEPOINTS. Other ideas were AUTO_SAVEPOINT, STATEMENT_SAVEPOINTS or STATEMENT_ROLLBACK. They aren't really good either... Patch is attached for review. Please decide if this can be included with PostgreSQL 8.0 or not. If so, I would like to add a regression test for the feature. In that case, could you please tell me where to put that one? Best Regards, Michael savepoints.patch Description: Binary data ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] doc patch for ssl in server
Dominic Mitchell [EMAIL PROTECTED] writes: + If verification of client certificates is required, place the + certificates of the acronymCA/acronym you wish to check for in + the file filenameroot.crt/filename in the data directory. When + present, a client certificate will be requested from the client + making the connection and it must have been signed by one of the + certificates present in filenameroot.crt/filename. If no + certificate is presented, the connection will be allowed to proceed + anway. That last statement is not actually correct, is it? AFAICS we do tell SSL to enforce certificates if we find a valid root.crt file. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] ALTER TABLE .. OWNER TO and sequences
Alvaro Herrera [EMAIL PROTECTED] writes: Here is a patch regarding ALTER TABLE ... OWNER and the sequences that were created by a SERIAL column. Applied with some changes. I tightened up the checks on the pg_depend entries, just for paranoia's sake. (At the moment I don't think there could be any entries that would wrongly get by the tests you had, but I'd rather verify that it's an INTERNAL dependency, for instance.) Additionally, it forbids directly changing the owner of a SERIAL sequence I did not apply this part because it's inconsistent with the behavior for indexes. If you want to argue that we should disallow changing index ownership separately as well, we can talk about that ... I also added some regression tests for ALTER TABLE ... OWNER, because previously there wasn't any. I didn't apply these either, because I thought them more likely to cause bogus regression failures than detect any real problems in the field. Two reasons they could do so are (1) running the regress tests as a superuser other than ID 1; (2) running the tests in an installation that already has a userid 42. We could avoid (2) by reporting user names instead of sysids, but that doesn't fix the superuser problem. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
