Hello Tom,
I started to look at this patch a bit. I'm quite confused by the fact
that some, but not all, of the possible FK action types now come in an
EACH variant. This makes no sense at all to me. ISTM that EACH is a
property of the FK constraint as a whole, that is that it says the
constraint is from array elements on the referencing side to column
values on the referenced side, rather than the normal case of column
values to column values.
The specification that Gianni posted applies only to v5 of the patch.
The original idea was indeed to have the whole foreign key to be defined
with an EACH property (initially we were actually thinking of the ARRAY
keyword following your advice, then for grammar reasons we opted for EACH).
However, during the actual development we faced some difficulties with
multi-column foreign keys.
Through discussions on this list and with the reviewer we opted to allow
the EACH keyword at column level.
We started with the case where at most one column is EACH, which is
easier to understand.
The case of two or more EACH columns in the same foreign key has been
left open for future development.
Why would the possible actions be affected, and why only these?
We had to add the EACH variant to two actions (EACH CASCADE and EACH
SET NULL), in order to leave users the flexibility to choose the
operation to be performed in case of delete or update of one or more
elements from the referenced table.
Some users indeed might prefer that, in case a referenced row is
deleted, the whole row is deleted (therefore they'd use the standard
CASCADE action). Others mights simply require that references to that
row is removed from the referencing array (therefore they'd use the
variant EACH CASCADE action). The same concept applies for SET NULL
(the whole array is set to NULL) and EACH SET NULL (referencing
elements are set to NULL).
Thank you.
Cheers,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele.bartol...@2ndquadrant.it | www.2ndQuadrant.it
