On Tue, 2007-01-23 at 10:39 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.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.
Yes, understood.
I just want it to work well with prepared queries also. That seems both
a reasonable goal and also achievable by caching in the way requested.
> 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.
We just store the Xid for which the cache is relevant then refresh the
cache if the cache is stale.
If you don't like the idea, say so. There's no need for anything more.
But those are minor points if you have stronger reservations about the
main proposal, which it sounds like you do.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com