> 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.
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 wi
[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 set
>> 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
> -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]
> [
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 the
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 go
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 ha
<[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 sou
>> 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,
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 thin
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
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
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
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 que
> > >> 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
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, l
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
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 se
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 choos
> > > 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 "c
> > 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 +0
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
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 i
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 mu
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
> reasona
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
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
> >
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
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
http://d
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
31 matches
Mail list logo
