Cool patch.
On Wed, 2007-04-04 at 18:36 +0000, FAST PostgreSQL wrote:
> The planner has to be taught to treat a DELETE/UPDATE WHERE CURRENT OF
> as a TidScan. Currently it follows the sequential scan route and
> extracts the current tuple based on the cursor position from the
> portal.
So you let the planner take a SeqScan, then override this at the top of
the executor? So if we EXPLAIN this it would say "SeqScan", but doesn't
actually do that? It works, but you're right it should do this the same
way as other plan types.
ISTM you need to add a special case in set_plain_rel_pathlist() in
optimizer/paths/allpaths.c similar to the special case for
relation_excluded_by_constraints(). In the case of an updateable cursor
there is only one path we want it to take, so a shortcut out is
appropriate, so the code would look similar-ish. Then you need to teach
the tidscan node to handle the case for an updateable cursor, i.e. a
call similar to GetCursorSlot() in TidNext() in nodeTidscan.c. That way
the rest of the executor machinery can get the slot for you.
Do we need additional code in any of the clients to handle this new
functionality correctly? ECPG etc?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com