Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-24 Thread Jim C. Nasby
On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: A \set variable would make sense to me. So Peter and Bruce like a \set variable, Chris and I like a different command. Seems like a tie ... more votes out there anywhere? If this will be

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-24 Thread chrisnospam
If this will be used interactively, it would be nice to have both. That way if you're running a bunch of cursor fetches, you can just do one \set, but if you only want to run one or a few you can use \gc and not mess around with \set. But I don't know how common interactive usage will be.

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Dave Page
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Treat Sent: 23 August 2006 04:16 To: pgsql-hackers@postgresql.org Cc: Peter Eisentraut; Tom Lane Subject: Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-23 Thread chrisnospam
To cut the Gordon knot I'm going to suggest we use: \set CURSOR_FETCH fetch_count and \g and ; are modified such that when they see this variable set to fetch_count 0 and the buffer is a select they would use the modified fetch/output code. Does this sound reasonable to everyone? OK

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-23 Thread Andrew Dunstan
[EMAIL PROTECTED] wrote: To cut the Gordon knot I'm going to suggest we use: ITYM Gordian - see http://en.wikipedia.org/wiki/Gordian_Knot cheers andrew ;-) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-22 Thread chrisnospam
True. They could even put it in .psqlrc if they want. Basically need a way to modify \g. Seems a \set is the way we have always done such modifications in the past. The big question is whether this is somehow different. Personally, I don't think so. If you want a \set variable, then at

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-22 Thread Tom Lane
[EMAIL PROTECTED] writes: To cut the Gordon knot I'm going to suggest we use: \set CURSOR_FETCH fetch_count and \g and ; are modified such that when they see this variable set to fetch_count 0 and the buffer is a select they would use the modified fetch/output code. Does this sound

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-22 Thread Robert Treat
On Thursday 17 August 2006 11:55, Peter Eisentraut wrote: Tom Lane wrote: Yeah, that experiment hasn't seemed to work all that well for me either. Do you have another idea to try, or do you just want to revert to the old way? Since almost the first day I hacked on PostgreSQL I have been

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Robert Treat wrote: ... some other tricks people have to make emails more manageable (anyone combine all pg mail to one folder?) Yes, all mine are in one folder, and I use elm ME. It is faster than a GUI email client. All my PG list mail goes into

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-22 Thread Michael Glaesemann
On Aug 23, 2006, at 12:15 , Robert Treat wrote: On Thursday 17 August 2006 11:55, Peter Eisentraut wrote: Tom Lane wrote: Yeah, that experiment hasn't seemed to work all that well for me either. Do you have another idea to try, or do you just want to revert to the old way? Since almost

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-19 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: True. They could even put it in .psqlrc if they want. Basically need a way to modify \g. Seems a \set is the way we have always done such modifications in the past. The big question is whether this is somehow different. Personally, I don't think so.

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-18 Thread Peter Eisentraut
Am Donnerstag, 17. August 2006 20:05 schrieb Chris Mair: \gc sounds like a good idea to me :) Strictly speaking, in the randomly defined grammer of psql, \gc is \g with an argument of 'c' (try it, it works). I'm not sure what use case you envision for this feature. Obviously, this is for

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-18 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: A \set variable would make sense to me. So Peter and Bruce like a \set variable, Chris and I like a different command. Seems like a tie ... more votes out there anywhere? regards, tom lane ---(end of

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-18 Thread David Fetter
On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: A \set variable would make sense to me. So Peter and Bruce like a \set variable, Chris and I like a different command. Seems like a tie ... more votes out there anywhere? It seems to me

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-18 Thread Bruce Momjian
David Fetter wrote: On Fri, Aug 18, 2006 at 10:16:12AM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: A \set variable would make sense to me. So Peter and Bruce like a \set variable, Chris and I like a different command. Seems like a tie ... more votes out there

Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Peter Eisentraut
Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all. -- Peter Eisentraut

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Peter Eisentraut wrote: Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all.

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Simon Riggs
On Thu, 2006-08-17 at 03:14 -0400, Bruce Momjian wrote: Peter Eisentraut wrote: Tom Lane wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? Ever since pgsql-patches replies started going to -hackers, threading doesn't work

pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-17 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes: Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all. Yeah, that experiment hasn't seemed to work all that well for me either. Do you have another idea to

Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Chris Mair
Hi, thanks for reviewing this :) attached is the new and fixed version of the patch for selecting large result sets from psql using cursors. The is_select_command bit is wrong because it doesn't allow for left parentheses in front of the SELECT keyword (something entirely reasonable

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-17 Thread Peter Eisentraut
Tom Lane wrote: Yeah, that experiment hasn't seemed to work all that well for me either. Do you have another idea to try, or do you just want to revert to the old way? Since almost the first day I hacked on PostgreSQL I have been filtering both lists into the same folder, so they pretty much

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Chris Mair wrote: At some point we ought to extend libpq enough to expose the V3-protocol feature that allows partial fetches from portals; that would be a cleaner way to implement this feature. However since nobody has yet proposed a good API for this in libpq, I don't object to

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Replying to myself... Patch with fix against current CVS is attached. Alvaro Herrera sent two fixes off-list: a typo and at the end of SendQueryUsingCursor I sould COMMIT, not ROLLBACK. So, one more version (6) that fixes these too is attached. Bye, Chris. PS: I'm keeping this on both lists

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Patch with fix against current CVS is attached. Forgot the attachment... soory. -- Chris Mair http://www.1006.org diff -rc pgsql.original/doc/src/sgml/ref/psql-ref.sgml pgsql/doc/src/sgml/ref/psql-ref.sgml *** pgsql.original/doc/src/sgml/ref/psql-ref.sgml 2006-08-17 16:50:58.0

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? True :) Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Chris Mair wrote: BTW, \u seems not to have any mnemonic value whatsoever ... isn't there some other name we could use? True :) Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char

Re: pgsql-patches reply-to (was Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors)

2006-08-17 Thread Jim C. Nasby
On Thu, Aug 17, 2006 at 09:20:43AM -0400, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Ever since pgsql-patches replies started going to -hackers, threading doesn't work anymore, so I for one can't tell what this refers to at all. Yeah, that experiment hasn't seemed to

Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-17 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Chris Mair wrote: Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I think a new backslash

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Chris Mair wrote: Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-17 Thread Chris Mair
Since buffer commands all have a single char I wanted a single char one too. The c for cursor was taken already, so i choose the u (second char in cursor). If somebody has a better suggestion, let us know ;) I think a new backslash variable isn't the way to go. I would use a

Re: [HACKERS] [PATCHES] selecting large result sets in psql using cursors

2006-08-16 Thread Tom Lane
Chris Mair [EMAIL PROTECTED] writes: attached is the new and fixed version of the patch for selecting large result sets from psql using cursors. The is_select_command bit is wrong because it doesn't allow for left parentheses in front of the SELECT keyword (something entirely reasonable when