Re: [PATCHES] eventlog fix
Would you send me documentation explaining how to register this DLL with the event logger on Win32? Ideally you could send me a diff against installation.sgml. Hello Bruce, After the DLL was in it target directory (C:\msys\1.0\local\pgsql\lib with make install) You can register the DLL to windows event log with the command Regsvr32 pgevent.dll or regsvr32 /s pgevent.dll whish is a silent mode. To uninstall, regsvr32 /u pgevent.dll will delete key add by the DLL in Windows registry. The DLL create the following entry: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\P ostgreSQL] with two values : EventMessageFile wish contains full path of DLL C:\msys\1.0\local\pgsql\lib\pgevent.dll TypesSupported : error type message send by postgresql Regsvr32 is a standard program located in %systemroot%\system32 Regards Laurent Ballester ---(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] pg_autovacuum integration patch
Some nitpicking on details: The comment above AutoVacMain() claims: ! * Main entry point for bgwriter process I also see a bunch of // comments, I think those are not appreciated. Haven't had time to look much at the actual functionality. Just did a quick look-through for win32 showstoppers, to be honest - didn't find any. (Doesn't mean they're not there, but..) Also, isn't it a bit unnecessary to do: sprintf(logbuffer,foo bar %s,whatever); elog(ERROR,logbuffer); why not just elog(ERROR,foo bar %s,whatever); [assuming I read the patch right - I still need some practice reading patches...] I also noticed: ! elog(ERROR, pg_autovacuum: GUC variable stats_row_level must be enabled.); ! elog(ERROR,Please fix the problems and try again.); If you use the ereport() call instead of elog, you can set the second one as a HINT. Since it's really the same error, I don't think you want multiple errors logged... I'll leave it to others to comment on the actual code - I'll take the easy way out and do nitpicking instead :-) I'll try to test this on win32 as soon as I have my tree back in compiling order. //Magnus -Original Message- From: Matthew T. O'Connor [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 8:19 AM To: PostgreSQL Patches Subject: [PATCHES] pg_autovacuum integration patch Ok, I have an 1st cut patch for pg_autovacuum integration into the backend. Please apply this patch to CVS or at least review and let me know what I need to change to get it applied to CVS. This patch requires that pg_autovacuum.c and .h are moved from contrib to src/backend/postmaster and src/include/postmaster respectively. I have also attached the pg_autovacuum.h file that needs to be put in src/include/catelog/ for the new pg_autovacuum system table. There is more to do for pg_autovacuum but I would like to get this patch included into CVS or at least get it rejected now so I can fix it before July 1. With this patch pg_autovacuum: * is a postmaster subprocess modeled after the bgwriter * uses elog for all output (I guessed at the appropriate elog levels) * used a new GUC variable to enable and disable pg_autovacuum * stores all it's volitile data in a new pg_autovacuum system table * allows admin to set per table thresholds Matthew O'Connor ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] pg_ctl service integration for WIN32
Here's a rough first cut, close to application state but not a finished work. Might be pushed for time over the next week, so if there are major criticisms it might need someone else to pick this up in the short term. I'll happily redo any minor bits. Comments? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a pg_ctl.patch Description: Binary data ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] pg_autovacuum integration patch
Magnus Hagander [EMAIL PROTECTED] writes: I also noticed: ! elog(ERROR, pg_autovacuum: GUC variable stats_row_level must be enabled.); ! elog(ERROR,Please fix the problems and try again.); If you use the ereport() call instead of elog, you can set the second one as a HINT. Since it's really the same error, I don't think you want multiple errors logged... Even more to the point, control will never *reach* the second elog(). Matthew clearly needs to spend more time studying the backend error message reporting mechanism. There is some documentation here: http://developer.postgresql.org/docs/postgres/error-message-reporting.html and the backend code is certainly chock-full of examples. 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] pg_autovacuum integration patch
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I also noticed: ! elog(ERROR, pg_autovacuum: GUC variable stats_row_level must be enabled.); ! elog(ERROR,Please fix the problems and try again.); If you use the ereport() call instead of elog, you can set the second one as a HINT. Since it's really the same error, I don't think you want multiple errors logged... Even more to the point, control will never *reach* the second elog(). Matthew clearly needs to spend more time studying the backend error message reporting mechanism. There is some documentation here: http://developer.postgresql.org/docs/postgres/error-message-reporting.html and the backend code is certainly chock-full of examples. Perhaps it's just as well that it isn't reached :-) Please fix the problems and try again doesn't strike me as a very useful message. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_ctl service integration for WIN32
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claudio Natoli Sent: 16 June 2004 14:49 To: [EMAIL PROTECTED] Subject: [PATCHES] pg_ctl service integration for WIN32 Here's a rough first cut, close to application state but not a finished work. Might be pushed for time over the next week, so if there are major criticisms it might need someone else to pick this up in the short term. I'll happily redo any minor bits. Comments? Looks OK to me at a quick glance. One thought though, whilst I like the idea of using service pause to do a SIGHUP from a convenience point of view, it's not exactly the expected behaviour and might leave the inexperienced user wondering why the server is still running normally. I'm on the fence regarding which way to to go with that though... Regards, Dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pg_ctl service integration for WIN32
Wow, my START /B code stays in pg_ctl? Interesting. I thought that was going to be ripped out. --- Claudio Natoli wrote: Here's a rough first cut, close to application state but not a finished work. Might be pushed for time over the next week, so if there are major criticisms it might need someone else to pick this up in the short term. I'll happily redo any minor bits. Comments? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Tablespaces
I'm starting to review this patch, and almost immediately came across
what seemed a spectacularly bad idea:
*** src/backend/storage/buffer/bufmgr.c8 May 2004 19:09:25 -1.165
--- src/backend/storage/buffer/bufmgr.c26 May 2004 06:21:01 -
***
*** 1148,1152
{
bufHdr = LocalBufferDescriptors[i];
! if (RelFileNodeEquals(bufHdr-tag.rnode, rnode))
{
bufHdr-flags = ~(BM_DIRTY | BM_JUST_DIRTIED);
--- 1148,1156
{
bufHdr = LocalBufferDescriptors[i];
! /* special case for default tblNode */
! if (RelFileNodeEquals(bufHdr-tag.rnode, rnode) ||
! (!OidIsValid(rnode.tblNode)
! bufHdr-tag.rnode.relNode == rnode.relNode
! bufHdr-tag.rnode.dbNode == rnode.dbNode))
{
bufHdr-flags = ~(BM_DIRTY | BM_JUST_DIRTIED);
There has got to be a better way than this. In the first place the
code seems able to seize on the wrong buffer if it's not checking
all three fields; in the second place, if the weak matching is correct
here why is it not needed everyplace else?
What's the purpose of this?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Tablespaces
Hi Tom,
On Wed, 16 Jun 2004, Tom Lane wrote:
I'm starting to review this patch, and almost immediately came across
what seemed a spectacularly bad idea:
*** src/backend/storage/buffer/bufmgr.c8 May 2004 19:09:25 -1.165
--- src/backend/storage/buffer/bufmgr.c26 May 2004 06:21:01 -
***
*** 1148,1152
{
bufHdr = LocalBufferDescriptors[i];
! if (RelFileNodeEquals(bufHdr-tag.rnode, rnode))
{
bufHdr-flags = ~(BM_DIRTY | BM_JUST_DIRTIED);
--- 1148,1156
{
bufHdr = LocalBufferDescriptors[i];
! /* special case for default tblNode */
! if (RelFileNodeEquals(bufHdr-tag.rnode, rnode) ||
! (!OidIsValid(rnode.tblNode)
! bufHdr-tag.rnode.relNode == rnode.relNode
! bufHdr-tag.rnode.dbNode == rnode.dbNode))
{
bufHdr-flags = ~(BM_DIRTY | BM_JUST_DIRTIED);
There has got to be a better way than this. In the first place the
code seems able to seize on the wrong buffer if it's not checking
all three fields; in the second place, if the weak matching is correct
here why is it not needed everyplace else?
Ahh. This is a hang over from some tests I was doing. I must have missed
it when I send the patch in. The patch should certainly work without this
change. I will verify later today when I have access to my development
machine.
Gavin
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] Nested transactions
On Tue, 2004-06-08 at 23:23, Alvaro Herrera wrote: Hackers, Here is the latest installment of the nested transactions patch. What's in the current patch: First of all, thank you for all your helpful comments recently. The patch looks impressively technical, but overall I'm not exactly sure what it does...I guess I'm just not clear why I would want it, except as the main technical pre-work to later syntax changes. I'm sure some short explanations would clear that up for me very quickly... :) The Todo items were: -Allow savepoints / nested transactions -Use nested transactions to prevent syntax errors from aborting a transaction both of which I thought I understood: The first one provides the SQL commands SAVEPOINT and ROLLBACK TO SAVEPOINT as with Oracle/DB2, and also now ANSI SQL if I recall... The second one again provides Oracle/DB2 support by conforming to their interpretation of the ANSI transactional semantics definition. i.e. one statement failure doesn't roll back the transaction, just the statement that failed. Being able to issue multiple BEGIN/END pairs isn't really (to me) the same thing as the above, nor do I understand why I'd ever want to do that - especially down to N levels Perhaps what I've just asked about is trivial icing on the cake you've just baked, so forgive me, but could you explain the outward form of your work and what that gives me? (or at least...what you think it gives you...which I accept may be different) Best regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] pg_ctl service integration for WIN32
Dave Page writes: Looks OK to me at a quick glance. One thought though, whilst I like the idea of using service pause to do a SIGHUP from a convenience point of view, it's not exactly the expected behaviour and might leave the inexperienced user wondering why the server is still running normally. I'm on the fence regarding which way to to go with that though... Likewise, I have no strong feelings either way. Apparently it is an accepted paradigm. Subconsciously, I must be against it, as I failed to pass a flag to enable the Pause/SIGHUP operation. :-) Amended patch attached. Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a pg_ctl.patch Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Nested transactions
I agree with Simon's comments. And to them I would add: I had assumed that the requirements for 'nested transactions' was following some standard definition or specification (i.e. the ANSI SQL spec). But from what I can tell, we are rolling our own definition here, not following a specification or standard, and not following any of the other major commercial databases lead. I think venturing out on our own and inventing new symantics for transactions and sql syntax to support them without giving this a lot of thought is bound to lead to problems. Perhaps I am completely wrong here and there is a clear standard or spec that is being implemented, if so, please let me know what that is as it would help me in better understanding this patch. I have been reviewing what Oracle does in this area and it doesn't at all resemble what this patch is exposing (especially as far as syntax goes). I plan to look at DB2 and MSSQL next. thanks, --Barry Simon Riggs wrote: On Tue, 2004-06-08 at 23:23, Alvaro Herrera wrote: Hackers, Here is the latest installment of the nested transactions patch. What's in the current patch: First of all, thank you for all your helpful comments recently. The patch looks impressively technical, but overall I'm not exactly sure what it does...I guess I'm just not clear why I would want it, except as the main technical pre-work to later syntax changes. I'm sure some short explanations would clear that up for me very quickly... :) The Todo items were: -Allow savepoints / nested transactions -Use nested transactions to prevent syntax errors from aborting a transaction both of which I thought I understood: The first one provides the SQL commands SAVEPOINT and ROLLBACK TO SAVEPOINT as with Oracle/DB2, and also now ANSI SQL if I recall... The second one again provides Oracle/DB2 support by conforming to their interpretation of the ANSI transactional semantics definition. i.e. one statement failure doesn't roll back the transaction, just the statement that failed. Being able to issue multiple BEGIN/END pairs isn't really (to me) the same thing as the above, nor do I understand why I'd ever want to do that - especially down to N levels Perhaps what I've just asked about is trivial icing on the cake you've just baked, so forgive me, but could you explain the outward form of your work and what that gives me? (or at least...what you think it gives you...which I accept may be different) Best regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(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] Nested transactions
Barry Lind wrote: I agree with Simon's comments. And to them I would add: I had assumed that the requirements for 'nested transactions' was following some standard definition or specification (i.e. the ANSI SQL spec). But from what I can tell, we are rolling our own definition here, not following a specification or standard, and not following any of the other major commercial databases lead. I think venturing out on our own and inventing new symantics for transactions and sql syntax to support them without giving this a lot of thought is bound to lead to problems. Perhaps I am completely wrong here and there is a clear standard or spec that is being implemented, if so, please let me know what that is as it would help me in better understanding this patch. I have been reviewing what Oracle does in this area and it doesn't at all resemble what this patch is exposing (especially as far as syntax goes). I plan to look at DB2 and MSSQL next. I realized about three weeks ago that our syntax for nested transactions doesn't follow anyone else's method. I think I might be the person who suggested the idea because it seemed more logical to me to allow BEGIN;BEGIN;COMMIT;COMMIT rather than naming arbitrary locations as savepoints and doing a rollback to that savepoint name. And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? I assume we overwrite the original, but using nested transaction syntax seems much clearer. Basically, we have to implement this in a nested way. Once it is done, we can add the window dressing to support the ANSI syntax. -- 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 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Nested transactions
On Wed, Jun 16, 2004 at 11:45:36PM +0100, Simon Riggs wrote: The patch looks impressively technical, but overall I'm not exactly sure what it does...I guess I'm just not clear why I would want it, except as the main technical pre-work to later syntax changes. I'm sure some short explanations would clear that up for me very quickly... :) Right. I have never intended to be implementing a known SQL standard feature. What I'm doing is allowing the whole backend to go back to a know state after an error is encountered. With this in place, implementing SAVEPOINTs the way SQL expects them to work appears to be a very trivial exercise. Perhaps what I've just asked about is trivial icing on the cake you've just baked, I think this phrase very precisely describes it. At least, that's what I expect. You may not see it, but a savepoint is just the start of a nested transaction in disguise. Consider: begin; insert into foo values (1); savepoint dammit; insert into foo values (2); select foo; -- fails rollback to dammit; insert into foo values (3); commit; You expect the transaction to finish with tuples 1 and 3 in table foo, right? Well, this is exactly the same as begin; insert into foo values (1); begin; -- dammit insert into foo values (2); select foo; -- fails, goes to aborted state rollback; insert into foo values (3); commit; So all that's needed for the former to work is to be able to define a name for a transaction (using a cute syntax) and being able to rollback to it. Definitely trivial, after all the work I have put into making the latter work. In extant releases you can only do this: begin; insert into foo values (1); insert into foo values (2); select foo; -- oops, can't go back! rollback; begin; insert into foo values (1); insert into foo values (3); commit; You are forced to send all the commands before the aborting one to the server again. And there's no way to undo a command in the transaction, short of aborting it completely. I don't know what Oracle or other DBMSs expect in this area. Anyone care to give me a few pointers? If I'm missing something, I want to know as soon as possible. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are. -- Charles J. Sykes' advice to teenagers ---(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] Nested transactions
And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? I assume we overwrite the original, but using nested transaction syntax seems much clearer. It also seems in this example that func_call() probably shouldn't have permission to rollback to savepoint x? Otherwise it would get...weird. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Nested transactions
On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote: And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? I assume we overwrite the original, but using nested transaction syntax seems much clearer. It also seems in this example that func_call() probably shouldn't have permission to rollback to savepoint x? Otherwise it would get...weird. I don't think we should explicitly forbid it. I think it should be forbidden to close the outermost transaction inside a function (else the function would not be able to terminate correctly), but for levels before that one it'd be OK. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Cuando mañana llegue pelearemos segun lo que mañana exija (Mowgli) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Nested transactions
Christopher Kings-Lynne wrote: And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? I assume we overwrite the original, but using nested transaction syntax seems much clearer. It also seems in this example that func_call() probably shouldn't have permission to rollback to savepoint x? Otherwise it would get...weird. Yes, weird. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Nested transactions
On Wed, Jun 16, 2004 at 09:36:33PM -0400, Bruce Momjian wrote: And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? Hm, that's a good question. What happens if you define two savepoints with the same name? According to SQL2003, the previous savepoint is destroyed, but it's not clear to me whether this means rolling back all of its changes or just forgetting it. What's clear is that you can roll back only to the latest one. Also, in SQL2003 there can be multiple savepoint levels. I think for a first implementation it would be fine if we had only one level. It would, wouldn't it? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Estoy de acuerdo contigo en que la verdad absoluta no existe... El problema es que la mentira sí existe y tu estás mintiendo (G. Lama) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Nested transactions
Alvaro Herrera wrote: On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote: And consider this case: BEGIN; ... SAVEPOINT x; SELECT func_call(); SELECT func_call(); COMMIT; Now if func_call has a savepoint, it is really nested because it can't know whether the savepoint X will be used to roll back, so its status is dependent on the status of X. Now, if we used savepoints in func_call, what happens in the second function call when we define a savepoint with the same name? I assume we overwrite the original, but using nested transaction syntax seems much clearer. It also seems in this example that func_call() probably shouldn't have permission to rollback to savepoint x? Otherwise it would get...weird. I don't think we should explicitly forbid it. I think it should be forbidden to close the outermost transaction inside a function (else the function would not be able to terminate correctly), but for levels before that one it'd be OK. True. I see no reason to disallow it. Alvaro, you mentioned savepoint levels, and I assume this to work around cases where they would need the nested transactions that we are implementing. -- 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 4: Don't 'kill -9' the postmaster
[PATCHES] Some index entries
The attached patch adds some index entries pointing to the cursor
reference pages. Please apply.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C Programmers)
Index: doc/src/sgml/ref/close.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/close.sgml,v
retrieving revision 1.20
diff -c -r1.20 close.sgml
*** doc/src/sgml/ref/close.sgml 29 Nov 2003 19:51:38 - 1.20
--- doc/src/sgml/ref/close.sgml 17 Jun 2004 02:37:27 -
***
*** 18,23
--- 18,28
primaryCLOSE/primary
/indexterm
+ indexterm zone=sql-close
+ primarycursor/primary
+ secondaryCLOSE/secondary
+ /indexterm
+
refsynopsisdiv
synopsis
CLOSE replaceable class=PARAMETERname/replaceable
Index: doc/src/sgml/ref/declare.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/declare.sgml,v
retrieving revision 1.30
diff -c -r1.30 declare.sgml
*** doc/src/sgml/ref/declare.sgml 29 Nov 2003 19:51:38 - 1.30
--- doc/src/sgml/ref/declare.sgml 17 Jun 2004 02:38:28 -
***
*** 18,23
--- 18,28
primaryDECLARE/primary
/indexterm
+ indexterm zone=sql-declare
+ primarycursor/primary
+ secondaryDECLARE/secondary
+ /indexterm
+
refsynopsisdiv
synopsis
DECLARE replaceable class=parametername/replaceable [ BINARY ] [ INSENSITIVE ]
[ [ NO ] SCROLL ]
Index: doc/src/sgml/ref/fetch.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/fetch.sgml,v
retrieving revision 1.36
diff -c -r1.36 fetch.sgml
*** doc/src/sgml/ref/fetch.sgml 23 Mar 2004 22:57:09 - 1.36
--- doc/src/sgml/ref/fetch.sgml 17 Jun 2004 03:14:41 -
***
*** 18,23
--- 18,28
primaryFETCH/primary
/indexterm
+ indexterm zone=sql-fetch
+ primarycursor/primary
+ secondaryFETCH/secondary
+ /indexterm
+
refsynopsisdiv
synopsis
FETCH [ replaceable class=PARAMETERdirection/replaceable { FROM | IN } ]
replaceable class=PARAMETERcursorname/replaceable
Index: doc/src/sgml/ref/move.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/move.sgml,v
retrieving revision 1.27
diff -c -r1.27 move.sgml
*** doc/src/sgml/ref/move.sgml 23 Mar 2004 22:39:22 - 1.27
--- doc/src/sgml/ref/move.sgml 17 Jun 2004 02:38:14 -
***
*** 18,23
--- 18,28
primaryMOVE/primary
/indexterm
+ indexterm zone=sql-move
+ primarycursor/primary
+ secondaryMOVE/secondary
+ /indexterm
+
refsynopsisdiv
synopsis
MOVE [ replaceable class=PARAMETERdirection/replaceable { FROM | IN } ]
replaceable class=PARAMETERcursorname/replaceable
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
