On 8 January 2016 at 05:08, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2016/01/07 21:50, Etsuro Fujita wrote: >> >> On 2016/01/06 20:37, Thom Brown wrote: >>> >>> On 25 December 2015 at 10:00, Etsuro Fujita >>> <fujita.ets...@lab.ntt.co.jp> wrote: >>>> >>>> Attached is an updated version of the patch, which is >>>> still WIP, but I'd be happy if I could get any feedback. > > >>> I've run into an issue: >>> >>> *# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING >>> tableoid::regclass; >>> ERROR: >>> CONTEXT: Remote SQL command: UPDATE public.customers SET id = 22 >>> WHERE ((id = 16)) RETURNING NULL > > >> Will fix. > > > While working on this, I noticed that the existing postgres_fdw system shows > similar behavior, so I changed the subject. > > IIUC, the reason for that is when the local query specifies "RETURNING > tableoid::regclass", the FDW has fmstate->has_returning=false while the > remote query executed at ModifyTable has "RETURNING NULL", as shown in the > above example; that would cause an abnormal exit in executing the remote > query in postgresExecForeignUpdate, since that the FDW would get > PGRES_TUPLES_OK as a result of the query while the FDW would think that the > right result to get should be PGRES_COMMAND_OK, from the flag > fmstate->has_returning=false. > > Attached is a patch to fix that.
I can't apply this patch in tandem with FDW DML pushdown patch (either v2 or v3). Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
