I've been deep in the FDW APIs lately and have come up with a couple of
questions about the [user-facing documentation][1].
# 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
[1]: http://www.postgresql.org/docs/9.3/static/fdw-callbacks.html
