On 2018/05/09 23:57, Robert Haas wrote:
> For right now, I think the options are (1) throw an ERROR if we
> encounter a foreign table or (2) silently skip the foreign table. I
> think (2) is defensible for non-UNIQUE indexes, because the index is
> just a performance optimization.
Along with others, my +1 to option 1.
> However, for UNIQUE indexes, at
> least, it seems like we'd better do (1), because a major point of such
> an index is to enforce a constraint; we can't allege that we have such
> a constraint if foreign tables are just silently skipped.
While I agree with this, let me point out that we do allow inherited check
constraints on foreign tables that are not actually enforced locally.
create table p (a int) partition by range (a);
create table p1 partition of p for values from (minvalue) to (1);
create table p2base (a int);
create foreign table p2 partition of p for values from (1) to (maxvalue)
server loopback options (table_name 'p2base');
alter table p add check (a between -1000 and 1000);
-- routed to foreign partition, which doesn't enforce check constraints
insert into p values (1001);
INSERT 0 1
-- whereas, local partition does
insert into p values (-1001);
ERROR: new row for relation "p1" violates check constraint "p_a_check"
DETAIL: Failing row contains (-1001).
We have to do the following to prevent that.
alter table p2base add check (a between -1000 and 1000);
insert into p values (1001);
ERROR: new row for relation "p2base" violates check constraint
"p2base_a_check"
DETAIL: Failing row contains (1001).
CONTEXT: remote SQL command: INSERT INTO public.p2base(a) VALUES ($1)
Thanks,
Amit
