Re: [PATCH] Support for Array ELEMENT Foreign Keys
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Support for Array ELEMENT Foreign Keys |
Дата | |
Msg-id | 21894.1350937343@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Support for Array ELEMENT Foreign Keys (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Support for Array ELEMENT Foreign Keys
Re: [PATCH] Support for Array ELEMENT Foreign Keys |
Список | 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 по дате отправления: