From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it> |
Subject: | Re: [PATCH] Support for Array ELEMENT Foreign Keys |
Date: | 2012-10-23 17:56:26 |
Message-ID: | 5086DA4A.4040306@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/22/12 4:22 PM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, I think if that's the best we can do, you original proposal of
>> ditching the column constraint syntax altogether might be for the
>> best. I wasn't too excited about that before, but I think having two
>> different syntaxes is going to be even worse. In some ways, it's
>> actually sort of sensible, because the referring side isn't really the
>> column itself; it's some value extracted therefrom. You can imagine
>> other variants of that as well, such as the recently-suggested
>
>> FOREIGN KEY ((somecol).member_name) REFERENCES othertab (doohicky)
>
>> Now, what would the column-constraint version of that look like? Is
>> it even sensible to think that there SHOULD be a column-constraint
>> version of that? I'm not convinced it is sensible, so maybe decreeing
>> that the table constraint version must be used to handle all
>> non-trivial cases is more sensible than I initially thought.
>
> I could easily go with that ...
I'm getting around to that conclusion as well.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-10-23 18:45:09 | Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Previous Message | Peter Eisentraut | 2012-10-23 16:53:14 | Re: Successor of MD5 authentication, let's use SCRAM |