On Thu, Feb 14, 2013 at 6:45 PM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> Shigeru Hanada wrote:
>> Tom Lane wrote:
>>> It ought to be pulling the rows back a few at a time, and
>>> that's not going to work well if multiple scans are sharing the same
>>> connection. (We might be able to dodge that by declaring a cursor
>>> for each scan, but I'm not convinced that such a solution will scale up
>>> to writable foreign tables, nested queries, subtransactions, etc.)
>>
>> Indeed the FDW used CURSOR in older versions. Sorry for that I have
>> not looked writable foreign table patch closely yet, but it would
>> require (may be multiple) remote update query executions during
>> scanning?
>
> It would for example call ExecForeignUpdate after each call to
> IterateForeignScan that produces a row that meets the UPDATE
> condition.
Thanks! It seems that ExecForeignUpdate needs another connection for
update query, or we need to retrieve all results at the first Iterate
call to prepare for possible subsequent update query.
--
Shigeru HANADA