Horton

Re: [PATCH] Support for foreign keys with arrays

Gabriele Bartolini <gabriele.bartolini@2ndquadrant.it>

View thread
From: Gabriele Bartolini <gabriele.bartolini@2ndQuadrant.it>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Marco Nenciarini <marco.nenciarini@2ndQuadrant.it>, pgsql-hackers@postgresql.org, Noah Misch <noah@leadboat.com>
Date: 2012-03-26T14:03:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow LEAKPROOF functions for better performance of security views.

  2. Improve labeling of pg_test_fsync open_sync test output.

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.bartolini@2ndQuadrant.it | www.2ndQuadrant.it