Skip site navigation (1) Skip section navigation (2)

Re: move 0 behaviour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Dave Cramer <dave(at)fastcrypt(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: move 0 behaviour
Date: 2002-10-30 18:19:27
Message-ID: 213.1036001967@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-jdbc
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I did some research on this.  It turns out the parser uses 0 for ALL, so
> when you do a FETCH ALL it is passing zero.  Now, when you do MOVE 0,
> you are really asking for FETCH ALL and all the tuples are thrown away
> because of the MOVE.

Yeah.  I think this is a bug and "MOVE 0" ought to be a no-op ... but
changing it requires a different parsetree representation for MOVE ALL,
which is tedious enough that it hasn't gotten done yet.

> I have the following patch which just documents the fact that MOVE 0
> goes to the end of the cursor.  It does not change any behavior, just
> document it.

It should be documented as behavior that is likely to change.  Also,
I believe FETCH 0 has the same issue.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Larry RosenmanDate: 2002-10-30 18:23:06
Subject: Re: 7.3b3 ok on unixware 71[12] here
Previous:From: Olivier PRENANTDate: 2002-10-30 18:16:26
Subject: Re: 7.3b3 ok on unixware 71[12] here

pgsql-jdbc by date

Next:From: Peter EisentrautDate: 2002-10-30 18:32:12
Subject: Re: move 0 behaviour
Previous:From: Barry LindDate: 2002-10-30 18:03:43
Subject: Re: optional package?

pgsql-general by date

Next:From: Francisco ReyesDate: 2002-10-30 18:21:53
Subject: Replacing a table
Previous:From: Stephan SzaboDate: 2002-10-30 18:19:02
Subject: Re: permission prob: granted, but still denied

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group