From: | Gabriele Bartolini <gabriele(dot)bartolini(at)2ndQuadrant(dot)it> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Marco Nenciarini <marco(dot)nenciarini(at)2ndQuadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Support for foreign keys with arrays |
Date: | 2012-01-31 15:55:42 |
Message-ID: | 4F280EFE.1080604@2ndQuadrant.it |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Noah,
Il 21/01/12 21:42, Noah Misch ha scritto:
> On Sat, Jan 14, 2012 at 08:18:48PM +0100, Marco Nenciarini wrote:
> I greatly like that name; it would still make sense for other
> aggregate types, should we ever expand its use. Please complete the
> name change: the documentation, catalog entries, etc should all call
> them something like "each foreign key constraints" (I don't
> particularly like that exact wording).
Ok, we'll go with "EACH Foreign Key Constraints" but I would allow the
synonym "Foreign Key Array", especially in the documentation.
> How about: FOREIGN KEY(col_a, EACH col_b, col_c) REFERENCES pktable
> (a, b, c)
We really like this syntax. However, as also Simon suggested, we'd go
for switching to this syntax, but stick to a simpler implementation for
9.2. We will then be able to expand the functionality, by keeping the
same syntax, from 9.3.
> To complete the ARRAY -> EACH transition, I would suggest names like
> CASCADE EACH/SET EACH NULL.
Sounds perfect.
Marco will go through all your comments and will send version 3 shortly.
Thank you,
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 | Alvaro Herrera | 2012-01-31 15:55:54 | Re: Dry-run mode for pg_archivecleanup |
Previous Message | Andrew Dunstan | 2012-01-31 15:54:28 | Re: [GENERAL] pg_dump -s dumps data?! |