Re: [HACKERS] ECPG regression failures on OpenBSD

2006-09-06 Thread chrisnospam
> Michael, if you want shell access to guppy, just contact me privately. > Warning: guppy too, is somewhat dated (1:10 hours for the make step) :/ Michael, did you receive my private mail yesterday? (just want to make sure it wasn't blocked by an overzealous spam filter) Bye, Chris. -- Chris M

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

2006-08-28 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 reasona

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: [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 ev

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,