Horton

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, Pg Hackers <pgsql-hackers@postgresql.org>, Rushabh Lathia <rushabh.lathia@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Date: 2018-02-07T23:01:53Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> I spent a while reading through this today.  I see a few decisions
> here or there that are debatable, in the sense that somebody else
> might have chosen to do it differently, but I don't see anything that
> actually looks wrong.  So, committed.

The buildfarm's opinion of it is lower than yours.  Just eyeballing
the failures, I'd say there was some naivete about the reproducibility
of tuple CTIDs across different platforms.  Is there a good reason
these test cases need to print CTID?

			regards, tom lane

Commits

  1. Temporarily instrument postgres_fdw test to look for statistics changes.

  2. postgres_fdw: Fourth attempt to stabilize regression tests.

  3. postgres_fdw: Third attempt to stabilize regression tests.

  4. postgres_fdw: Attmempt to stabilize regression tests.

  5. postgres_fdw: Push down UPDATE/DELETE joins to remote servers.