| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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-22 20:22:23 |
| Message-ID: | 21894.1350937343@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2012-10-22 20:53:48 | Re: ToDo: KNN Search should to support DISTINCT clasuse? |
| Previous Message | Robert Haas | 2012-10-22 20:17:42 | Re: [PATCH] Support for Array ELEMENT Foreign Keys |