Re: [PATCH] Support for foreign keys with arrays - Mailing list pgsql-hackers

From Gabriele Bartolini
Subject Re: [PATCH] Support for foreign keys with arrays
Date
Msg-id 4EE31CB9.90005@2ndQuadrant.it
Whole thread Raw
In response to Re: [PATCH] Support for foreign keys with arrays  (Noah Misch <noah@leadboat.com>)
Responses Re: [PATCH] Support for foreign keys with arrays
List 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.bartolini@2ndQuadrant.it
|www.2ndQuadrant.it
 



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Next
From: Greg Smith
Date:
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp