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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"
Дата
Msg-id 22096.1226701445@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"  (Gregory Stark <stark@enterprisedb.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Okay, DLLIMPORT is making me crazy
Следующее
От: "Robert Haas"
Дата:
Сообщение: Re: "ORDER BY" clause prevents "UPDATE WHERE CURRENT OF"