Re: LIMIT for UPDATE and DELETE

On 9/10/14 11:25 AM, Etsuro Fujita wrote:
> The reason is because I think that after implementing #2, we should
> re-implement this feature by extending the planner to produce a plan
> tree such as ModifyTable+Limit+Append, maybe with LockRows below the
> Limit node.  Such an approach would prevent duplication of the LIMIT
> code in ModifyTable, making the ModifyTable code more simple, I think.

You can already change *this patch* to do ModifyTable <- Limit <- 
LockRows.  If we think that's what we want, we should rewrite this patch 
right now.  This isn't a reason not to implement LIMIT without ORDER BY.

Like I said upthread, I think LockRows is a bad idea, but I'll need to 
run some performance tests first.  But whichever method we decide to 
implement for this patch shouldn't need to be touched when the changes 
to UPDATE land, so your reasoning is incorrect.


.marko