From: | Gabriele Bartolini <gabriele(dot)bartolini(at)2ndQuadrant(dot)it> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it> |
Subject: | Re: [PATCH] Support for foreign keys with arrays |
Date: | 2011-12-10 08:47:53 |
Message-ID: | 4EE31CB9.90005@2ndQuadrant.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Noah,
thanks for your feedback.
Il 20/11/11 14:05, Noah Misch ha scritto:
> What about making ON UPDATE CASCADE an error? That way, we can say that ARRAY
> <action> always applies to array elements, and plain<action> always applies to
> entire rows.
>
> SET DEFAULT should now be fine to allow. It's ARRAY SET DEFAULT, in your new
> terminology, that wouldn't make sense.
I have tried to gather your ideas with Gianni's and come to a
compromise, which I hope you can both agree on.
The reason why I would be inclined to leave CASCADE act on rows (rather
than array elements as Gianni suggests) is for backward compatibility
(people that are already using referential integrity based on array
values). For the same reason, I am not sure whether we should raise an
error on update, but will leave this for later.
So, here is a summary:
--------------- --------- ---------
| ON | ON |
Action | DELETE | UPDATE |
--------------- --------- ---------
CASCADE | Row | Error |
SET NULL | Row | Row |
SET DEFAULT | Row | Row |
ARRAY CASCADE | Element | Element |
ARRAY SET NULL | Element | Element |
NO ACTION | - | - |
RESTRICT | - | - |
--------------- --------- ---------
If that's fine with you guys, Marco and I will refactor the development
based on these assumptions.
Thanks,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele(dot)bartolini(at)2ndQuadrant(dot)it | www.2ndQuadrant.it
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-12-10 12:29:39 | Re: [REVIEW] pg_last_xact_insert_timestamp |
Previous Message | Greg Smith | 2011-12-10 07:49:40 | Re: pgsql_fdw, FDW for PostgreSQL server |