From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Defining a foreign key with a duplicate column is broken |
Date: | 2014-08-09 17:49:27 |
Message-ID: | 16463.1407606567@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Sat, Aug 9, 2014 at 3:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There's no need for a new error message I think, because we should just
>> ignore such indexes. After all, there might be a valid matching index
>> later on.
> hmm, but if the user attempts to define the foreign key that contains a
> duplicate column in the REFERENCES part, then we'll never "find" any
> indexes, so there's no point in looking at all.
OK, now that I'm a bit more awake, I agree with that.
> I've attached a version of the patch that's a little smarter when it comes
> to doing the duplicate checks in the attnums array...
Applied with some cosmetic adjustments. I didn't bother with the
regression test either --- this doesn't seem like something that needs
permanent memorialization as a regression test.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-08-09 17:52:32 | Re: jsonb format is pessimal for toast compression |
Previous Message | Andres Freund | 2014-08-09 16:54:55 | Re: Reporting the commit LSN at commit time |