(2019/03/06 13:53), Amit Langote wrote:
On 2019/03/06 13:30, David Rowley wrote:
I think you missed my point. If there's no special support for "tuple
moving", as you say, then what help is it to tell the user "if the FDW
supports tuple routing"? The answer is, it's not any help. How would
the user check such a fact?
Hmm, maybe getting the following error, like one would get in PG 10 when
using postgres_fdw-managed partitions:
ERROR: cannot route inserted tuples to a foreign table
Getting the above error is perhaps not the best way for a user to learn of
this fact, but maybe we (and hopefully other FDW authors) mention this in
the documentation?
+1
As far as I can tell, this is just the requirements as defined in
CheckValidResultRel() for CMD_INSERT. Fragments of which I pasted
above.
Only supporting INSERT doesn't suffice though. An FDW which intends to
support tuple routing and hence 1-way tuple moving needs to updated like
postgres_fdw was in PG 11.
That's right; the "if the FDW supports it" in the documentation refers
to the FDW's support for the callback functions BeginForeignInsert() and
EndForeignInsert() described in 57.2.4. FDW Routines For Updating
Foreign Tables [1] in addition to ExecForeignInsert(), as stated there:
"Tuples inserted into a partitioned table by INSERT or COPY FROM are
routed to partitions. If an FDW supports routable foreign-table
partitions, it should also provide the following callback functions."
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/docs/current/fdw-callbacks.html#FDW-CALLBACKS-UPDATE
