At 2011-12-28 01:47:20,"Tom Lane" t...@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)?
