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
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" |