Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"
Date: 2008-11-14 22:27:48
Message-ID: 603c8f070811141427j1609ad09s84f636cee67d0a30@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> [ dept of second thoughts... ] Actually, given that he said FOR UPDATE,
> the plan should be propagating the tuple identity through to top level
> so that execMain can do its thing. So in principle we could probably
> get the information without widespread changes. This would fit
> reasonably well with the spec's requirements too --- any but trivial
> cursors are not deemed updatable unless you say FOR UPDATE. But it
> would mean two completely independent implementations within
> execCurrent.c...

What's particularly unfortunate is Greg's comment that this would work
if the planner chose an index scan. Had I defined an index on the
columns in question, my code might have worked and been deployed to
production - and then broken if the planner changed its mind and
decided to use a seqscan after all.

ISTM any cursor that's going to be updated should specify WHERE UPDATE
in the query, but maybe that's not a hard requirement as of now.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-11-14 22:33:40 Re: Updated posix fadvise patch v19
Previous Message Tom Lane 2008-11-14 22:24:05 Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"