Re: Updatable cursors thoughts

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Sounds good. The cost is paid by the WHERE CURRENT OF query, not as an
> overhead on all cursors. Sounds like it will still be very fast too.

Yeah, there's zero added cost in the existing code paths, and the lookup
isn't really that expensive.

> Presumably still disallowing the WITH HOLD case.

Right --- once you've committed, you can't be sure the rows are still
there to look at.

I just finished revising the patch and am about to commit it. In the
event, my idea of a separate lookup function didn't work so well --- it
needed to be STABLE to be used in a tidscan qual, but it also needed to
be VOLATILE to prevent the planner from speculatively executing it
(resulting in premature failure if the cursor wasn't there at plan
time). So I ended up letting the special CurrentOfExpr node type
persist all the way through to execution. This required very minor
hackery in tidpath.c and nodeTidscan.c to accept such a node as a TID
qual; it would've taken something uglier to make the function
representation work.

One area that could still do with more work is getting the facility to
play nicely with views. However, it's probably premature to think about
that before we have updatable views that work well...

regards, tom lane