On Thu, Feb 14, 2013 at 6:45 PM, Albe Laurenz <laurenz.a...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
