From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposed feature: Selective Foreign Keys |
Date: | 2013-12-04 23:26:42 |
Message-ID: | 805981F6-F25E-4E80-8280-D7A0A7CC6D28@tomd.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 Dec 2013, at 03:48, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Well I guess we could say something like:
>>>
>>> FOREIGN KEY (a-col) WHERE (a-condition) REFERENCES b(b-col) WHERE
>>> (b-condition)
>>>
>
> OK, those make sense. I wonder whether this should be done via a USING clause on the constraint that pointed to the partial unique index. Or would that be too obscure?
Well you could put a USING clause on the end and it would read pretty unambiguously. Requiring that the user specify it rather than trying to guess which index to use would also probably be an easier path to getting that feature in, at least for a first cut.
I won’t be doing work towards putting a where clause on the referenced side just yet, though. One thing at a time.
Cheers
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2013-12-04 23:33:23 | Re: Performance optimization of btree binary search |
Previous Message | Tom Dunstan | 2013-12-04 23:19:54 | Re: Proposed feature: Selective Foreign Keys |