On 2017/10/04 21:28, Ashutosh Bapat wrote:
On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas <robertmh...@gmail.com> wrote:
On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
We can
check whether a row being sent from the local server to the foreign
server obeys WCO, but what foreign server does to that row is beyond
local server's scope.
But I think right now we're not checking the row being sent from the
local server, either.
We don't check the row *before* sending it to the remote server, but
check the row returned by ExecForeignInsert/ExecForeignUpdate, which is
allowed to have been changed by the remote server. In postgres_fdw, we
currently return the data actually inserted/updated if RETURNING/AFTER
TRIGGER present, but not if WCO only presents. So, for the postgres_fdw
foreign table, WCO is enforced on the data that was actually
inserted/updated if RETURNING/AFTER TRIGGER present and on the original
data core supplied if WCO only presents, which is inconsistent behavior.
Didn't 7086be6e3627c1ad797e32ebbdd232905b5f577f fix that?
No. The commit addressed another issue.
The WCO that is being ignored isn't a
constraint on the foreign table; it's a constraint on a view which
happens to reference the foreign table. It seems quite odd for the
"assume constraints are valid" property of the foreign table to
propagate back up into the view that references it.
Agreed.
The view with WCO is local but the modification which violates WCO is
being made on remote server by a trigger on remote table. Trying to
control that doesn't seem to be a good idea, just like we can't
control what rows get inserted on the foreign server when they violate
local constraints. I am using local constraints as an example of
precedence where we ignore what's happening on remote side and enforce
whatever we could enforce locally. Local server should make sure that
any rows sent from local server to the remote server do not violate
any local WCO.
Seems odd (and too restrictive) to me too.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
