Re: Another oddity in handling of WCO constraints in postgres_fdw

On 2017/10/03 18:16, Ashutosh Bapat wrote:
> Enforcing WCO constraints imposed by the local server on the row/DML
> being passed to the foreign server is fine, but trying to impose them
> on the row being inserted/updated at the foreign server looks odd. May
> be we should just leave this case as it is. I am comparing this case
> with the way we handle constraints on a foreign table.

Hmm, I think that would be okay in the case where WCO constraints match 
constraints on the foreign table, but I'm not sure that would be okay 
even in the case where WCO constraints don't match?  Consider:

create table bt (a int check (a % 2 = 0));
create foreign table ft (a int check (a % 2 = 0)) server loopback 
options (table_name 'bt');
create view rw_view_2 as select * from ft where a % 2 = 0 with check option;

In that case the WCO constraint matches the constraint on the foreign 
table, so there would be no need to ensure the WCO constraint locally 
(to make the explanation simple, we assume here that we don't have 
triggers on the remote end).  BUT: for another auto-updatable view 
defined using the same foreign table like this:

create view rw_view_4 as select * from ft where a % 4 = 0 with check option;

how is the WCO constraint (ie, a % 4 = 0) ensured remotely, which is 
different from the constraint on the foreign table (ie, a % 2 = 0)? 
Maybe I'm missing something, though.

Best regards,
Etsuro Fujita