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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate