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 5016A466.4070603@2ndQuadrant.it
Whole thread Raw
In response to Re: [PATCH] Support for foreign keys with arrays  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [PATCH] Support for foreign keys with arrays  (Simon Riggs <simon@2ndQuadrant.com>)
Re: [PATCH] Support for foreign keys with arrays  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi guys,<br /><br />    it is time to give another go to this patch. I would like to thank everyone for suggestions
andideas expressed through this list.<br /><br />    We are happy that "Part 0" of the patch has been committed
(array_remove()and array_replace() functions), which will be useful in "Part 2" (too early now to talk about it). Let's
notrush though and focus on "Part 1" of the patch. :)<br /><blockquote
cite="mid:CA+U5nMKvmv_c35D5W=O4boW1AAZFg+2qHKLbvXV3nJVdYgff8w@mail.gmail.com"type="cite"></blockquote>    First, I
wouldlike to find a unique and general term for this feature. We started with "Foreign keys with arrays" and ended up
with"EACH foreign keys". Following Peter's suggestion, we will use the "ELEMENT" keyword (so that maybe in the future
wecan extend the usage). Our proposals are:<br /><br /> * Array Foreign Key<br /> * Foreign Key Arrays<br /> * ELEMENT
ForeignKeys<br /> * ...<br /><br />    Which one is your favourite?<br /><br />    Secondly, we have decided to split
thepatch we proposed back in March in two smaller patches. The most important goal of "Part 1" is to find a generally
acceptedsyntax. By removing ACTION handling from "Part 1" (see limitations below), we believe that the community will
beable to contribute more to driving future directions and requirements. Based on Peter's comments, we would like to
proposethe use of the "ELEMENT" keyword, rather than the "EACH" keyword proposed in March. You can find three examples
atthe bottom of this email.<br /><br />    Finally, "Part 1" of this patch will have these limitations:<br /><br /> *
Onlyone <code>ELEMENT</code> column allowed in a multi-column key (same as the proposed patch in March)<br /> *
Supportedactions<code>:<br />  * NO ACTION</code><code><br />  * RESTRICT</code><br /><br /> Cheers,<br /> Gabriele<br
/><br/><br /> Example 1: inline usage<br /><br /><tt>CREATE TABLE drivers (<br />     driver_id integer PRIMARY KEY,<br
/>    first_name text,<br />     last_name text,<br />     ...<br /> );<br /><br /> CREATE TABLE races (<br />    
race_idinteger PRIMARY KEY,<br />     title text,<br />     race_day DATE,<br />     ...<br />     final_positions
integer[]ELEMENT REFERENCES drivers<br /> );</tt><br /><br /><br /><br /> Example 2: with FOREIGN KEY<br /><br
/><tt>CREATETABLE races (<br />     race_id integer PRIMARY KEY,<br />     title text,<br />     race_day DATE,<br />
   ...<br />     final_positions integer[],<br />     FOREIGN KEY (ELEMENT final_positions) REFERENCES drivers<br />
);<br/></tt><br /><br /><br /> Example 3: with ALTER TABLE<br /><br /><tt>CREATE TABLE races (<br />     race_id
integerPRIMARY KEY,<br />     title text,<br />     race_day DATE,<br />     ...<br />     final_positions integer[]<br
/>);<br /><br /> ALTER TABLE races ADD FOREIGN KEY (ELEMENT final_positions) REFERENCES drivers;<br /></tt><br /><pre
class="moz-signature"cols="72">-- Gabriele Bartolini - 2ndQuadrant ItaliaPostgreSQL Training, Services and Support<a
class="moz-txt-link-abbreviated"href="mailto:gabriele.bartolini@2ndQuadrant.it">gabriele.bartolini@2ndQuadrant.it</a> |
<aclass="moz-txt-link-abbreviated" href="http://www.2ndQuadrant.it">www.2ndQuadrant.it</a>
 
</pre>

pgsql-hackers by date:

Previous
From: Achim Domma
Date:
Subject: Passing tabular data around using python functions
Next
From: Simon Riggs
Date:
Subject: Re: [PATCH] Support for foreign keys with arrays