At 2011-12-28 01:47:20,"Tom Lane" tgl@sss.pgh.pa.us> wrote:
Yup. I don't particularly see this as a bug. If you were to manually
>rewind and rescan the cursor (ie, MOVE BACKWARD ALL and re-fetch),
>the function would be executed multiple times too. If you don't want
>that to happen, the best way would be to commit the transaction
>immediately, not fetch some rows and then commit.
>
> regards, tom lane
Why *with hold cursor* acts as *MOVE BACKWARD ALL & FETCH*?
Is this right or necessary? maybe they are not comparable, i doubt this analogy.
MOVE BACKWARD ALL & FETCH will cause cursor re-fetch?
Maybe pepole have different opinions for MOVE BACKWARD ALL & FETCH:
1. fetch from the old result-sets, not rescan(re-execute);
2. re-fetch and generate the new result-sets, cause plan re-execute again;
Now, pg acts as the second;
*Move* is not SQL standard, and does not clearly documented in pg document,
If we create *DestTuplestore* when first fetch, not in commit transaction, then:
1. we always fetch results from *DestTuplestore*;
2. if *DestTuplestore* is empty, we execute-plan and fill the results into *DestTuplestore*;
3. when rewind, just rewind *DestTuplestore*, not executor;
then we can implement the first action?
So, there are two questions here:
1. the Standard action of *MOVE BACKWARD ALL & FETCH*;
2. *with hold cursor* acts as *MOVE BACKWARD ALL & FETCH*, is this right(necessary)?