| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Francisco Reyes | 2002-10-30 18:21:53 | Replacing a table |
| Previous Message | Stephan Szabo | 2002-10-30 18:19:02 | Re: permission prob: granted, but still denied |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2002-10-30 18:23:06 | Re: 7.3b3 ok on unixware 71[12] here |
| Previous Message | Olivier PRENANT | 2002-10-30 18:16:26 | Re: 7.3b3 ok on unixware 71[12] here |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2002-10-30 18:32:12 | Re: move 0 behaviour |
| Previous Message | Barry Lind | 2002-10-30 18:03:43 | Re: optional package? |