On Mon, Oct 22, 2012 at 2:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm not thrilled with the inconsistency either, but given the > constraints we're under, it seems like the best we can do. (I feel, > as Andrew does, that shoving WHERE into the table-constraint syntax > would not be an improvement; but the column-constraint syntax really > needs to start with a fully-reserved word). Have you got a better > proposal?
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
