Re: [PATCH] Support for foreign keys with arrays
| От | Gabriele Bartolini |
|---|---|
| Тема | Re: [PATCH] Support for foreign keys with arrays |
| Дата | |
| Msg-id | 4F70774C.4040206@2ndQuadrant.it обсуждение исходный текст |
| Ответ на | Re: [PATCH] Support for foreign keys with arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Hello Tom,
Thank you.
Cheers,
Gabriele
> 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).
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.
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.
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).
Cheers,
Gabriele
-- Gabriele Bartolini - 2ndQuadrant ItaliaPostgreSQL Training, Services and Supportgabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it
В списке pgsql-hackers по дате отправления: