Hi,
On 2019/01/18 7:23, Alvaro Herrera wrote:
> On 2019-Jan-16, Amit Langote wrote:
>
>> Why not just move the code in clone_fk_constraints() that checks if the
>> constraint equivalent of the parent's constraint is present in the
>> partition and simply attach the two without creating a new copy for the
>> partition to a new function in tablecmds.c and call the function from both
>> clone_fk_constraints() and ATAddForeignKeyConstraint()? Attached is what
>> I'm thinking.
>
> Well, the whole point of my proposal is that the FK-creating code
> recurses to partitions by calling ATAddForeignKeyConstraint, and IMO
> that's the wrong level to recurse at; we should instead recurse by
> calling clone_fk_constraints() as a whole.
Sorry about the noise. I agree with the committed approach. With this,
ALTER TABLE ADD FOREIGN KEY's inheritance recursion path now looks
completely different from ALTER TABLE ADD CHECK's, but that's fine.
Actually, if we had the same "clone" approach for check constraints, which
both checks if a child already has the constraint being cloned and creates
one if not, we could do away with errors like the following:
create table p (a int, constraint check_a check (a > 0)) partition by list
create table p1 (a int);
alter table p attach partition p1 for values in (1);
ERROR: child table is missing constraint "check_a"
But of course that would be a different feature.
Thanks,
Amit
