Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"
Date
Msg-id 22096.1226701445@sss.pgh.pa.us
Whole thread Raw
In response to Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"  ("Robert Haas" <robertmhaas@gmail.com>)
Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Robert Haas" <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Okay, DLLIMPORT is making me crazy
Next
From: "Robert Haas"
Date:
Subject: Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"