| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Cc: | "FAST PostgreSQL" <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Updateable cursors |
| Date: | 2007-01-23 15:39:25 |
| Message-ID: | 19170.1169566765@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
>> This really isn't gonna work, because it assumes that the tuple that is
>> "current" at the instant of parsing is still going to be "current" at
>> execution time.
> Of course thats true, but you've misread my comment.
> The portal with the cursor in will not change, no matter how many times
> we execute WHERE CURRENT OF in another portal.
Really? The cursor portal will cease to exist as soon as the
transaction ends, but the prepared plan won't. A reasonable person
would expect that WHERE CURRENT OF will parse into a plan that just
stores the cursor name, and looks up the cursor at execution time.
> The OP suggested putting
> the current tuple pointer onto the portal data, so this will work.
No, as I read his message he was suggesting pulling data out of the
cursor portal at plan time so that no downstream (executor) changes
would be needed. That is certainly never going to be workable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2007-01-23 15:40:33 | Re: [HACKERS] Win32 WEXITSTATUS too |
| Previous Message | Tino Wildenhain | 2007-01-23 15:37:05 | Re: STOP all user access except for admin for a few minutes? |