Re: [PATCH] Support for Array ELEMENT Foreign Keys - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Support for Array ELEMENT Foreign Keys
Date
Msg-id 21894.1350937343@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Support for Array ELEMENT Foreign Keys  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] Support for Array ELEMENT Foreign Keys  (Peter Eisentraut <peter_e@gmx.net>)
Re: [PATCH] Support for Array ELEMENT Foreign Keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Support for Array ELEMENT Foreign Keys
Next
From: Pavel Stehule
Date:
Subject: Re: ToDo: KNN Search should to support DISTINCT clasuse?