From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, Postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF" |
Date: | 2008-11-14 22:24:05 |
Message-ID: | 22096.1226701445@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>> I found the following behavior surprising. Is there a reason for it?
>> This is 8.3.5. ...Robert
>>
>> rhaas=# DECLARE c CURSOR FOR SELECT id FROM test_table ORDER BY foo FOR UPDATE;
> Skimming the code we don't support WHERE CURRENT OF on a query which involves
> a Sort above the table specified. The way CURRENT OF works depends on the
> nature of the plan and depends on there being an active scan of the specified
> table. Since sort reads all its inputs in advance that information is lost by
> the time the results are output.
[ 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...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-14 22:27:48 | Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF" |
Previous Message | Magnus Hagander | 2008-11-14 22:11:07 | Re: Okay, DLLIMPORT is making me crazy |