--On 13. Juni 2014 13:46:38 -0400 Tom Lane <t...@sss.pgh.pa.us> wrote:
Imagine if `BeginForeignScan` set up a remote cursor and
`IterateForeignScan` just fetched _one tuple at a time_ (unlike the
current behavior where they are fetched in batches). The tuple would be
passed to `ExecForeignDelete` (as is required), but the remote cursor
would remain pointing at that tuple. Couldn't `ExecForeignDelete` just
call `DELETE FROM table WHERE CURRENT OF cursor` to then delete that
tuple?
No. This is not guaranteed (or even likely) to work in join cases: the
tuple to be updated/deleted might no longer be the current one of the
scan. You *must* arrange for the scan to return enough information to
uniquely identify the tuple later, and that generally means adding some
resjunk columns.
Yeah, this is exactly the trap i ran into while implementing the
informix_fdw driver. It used an updatable cursor to implement the modify
actions as you proposed first. Consider a query like
UPDATE remote SET f1 = t.id FROM local t WHERE t.id = f1
The planner might choose a hash join where the hash table is built by
forwarding the cursor via the foreign scan. You'll end up with the cursor
positioned at the end and you have no way to get it back "in sync" when the
modify action is actually called.
--
Thanks
Bernd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
