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: Noah Misch <noah@leadboat.com>
Cc: Marco Nenciarini <marco.nenciarini@2ndQuadrant.it>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-01-31T15:55:42Z
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.

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