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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers