Re: Updateable cursors patch

On Mon, 2 Apr 2007 03:15, Simon Riggs wrote:
> 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.
>

Yeah, currently EXPLAIN will give the wrong details. That's not ideal of
course. We will be fixing that soon. Thanks for the code tips.

> 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?
Psql's tab completion is one that quickly comes to mind. Along with the above
said fix, I can do this. Don't know too much about other clients....

Rgds,
Arul Shaji