Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw |
Дата | |
Msg-id | 60e94494-4e5d-afed-e482-b9ad1986bbf6@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw
|
Список | pgsql-hackers |
On 2017/10/04 21:28, Ashutosh Bapat wrote: > On Wed, Oct 4, 2017 at 5:32 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Oct 4, 2017 at 6:40 AM, Ashutosh Bapat >> <ashutosh.bapat@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
В списке pgsql-hackers по дате отправления: