I've been deep in the FDW APIs lately and have come up with a couple of questions about the [user-facing documentation].
# Requirement that DELETE use junk columns The bit I'm confused by is the parenthetical in this bit at the end of the section on `AddForeignUpdateTargets`: > If the AddForeignUpdateTargets pointer is set to NULL, no extra target > expressions are added. (This will make it impossible to implement DELETE > operations, though UPDATE may still be feasible if the FDW relies on an > unchanging primary key to identify rows.) Later on, the section on `ExecForeignDelete` says (emphasis mine): > The junk column(s) **must** be used to identify the tuple to be deleted. Why is this a requirement? At the moment, `postgres_fdw` asks remote machines for the `ctid` of tuples during a scan so it can use that `ctid` to create a targeted `DELETE` during `ExecForeignDelete`, but I think an alternative could avoid the use of the `ctid` junk column altogether... 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? Even if there is no guarantee that `IterateForeignScan` is called exactly once before each `ExecForeignDelete` call (which would remove the ability to have them cooperate using this single cursor), one could easily devise other storage backends that don't need "junk" columns to perform `DELETE` operations. So why the strong language around this functionality? # Examples of `NULL` return after modification Each of the `ExecForeign`- functions needs to return a tuple representing the row inserted, deleted, or modified. But each function's documentation contains an aside similar to this: > The return value is either a slot containing the data that was actually > inserted (this might differ from the data supplied, for example as a result > of trigger actions), or NULL if no row was actually inserted (again, > typically as a result of triggers). Is this even accurate in PostgreSQL 9.3? Can triggers fire against foreign tables? If so, can someone provide an example where the foreign scan has found a tuple, passed it to `ExecForeignDelete`, and then no delete takes place (i.e. `ExecForeignDelete` returns `NULL`)? As far as I can reason, if the foreign scan has found a tuple, the update and delete actions need to do _something_ with it. Maybe I'm missing something. --Jason : http://www.postgresql.org/docs/9.3/static/fdw-callbacks.html -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers