From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Another oddity in handling of WCO constraints in postgres_fdw |
Date: | 2017-10-05 09:08:50 |
Message-ID: | 60e94494-4e5d-afed-e482-b9ad1986bbf6@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/10/04 21:28, Ashutosh Bapat wrote:
> On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat
>> <ashutosh(dot)bapat(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-10-05 09:38:08 | Re: Partition-wise join for join between (declaratively) partitioned tables |
Previous Message | Thomas Munro | 2017-10-05 07:45:58 | Re: Parallel Hash take II |