From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15556: Duplicate key violations even when using ON CONFLICT DO UPDATE |
Date: | 2018-12-17 19:08:43 |
Message-ID: | CAH2-WznJS5zRurkyGFN964UUQujEUnf9pnMgH55WAG0+uaqamA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Dec 17, 2018 at 1:55 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> Below a self reproducing testcase for this behaviour.
>
> I would have expected the statement to either insert or update, but
> receiving
> the duplicate key violation is not something that I expected.
>
> Should I expect a duplicate key violation for the given table and
> statements?
The problem is that unique index inference isn't sophisticated enough
to recognize that the primary key ought to be inferred alongside the
two other unique indexes, which are expression indexes. This is hardly
surprising -- why would an expression index need to be created that
was exactly equivalent to the primary key? Actually, it's impossible
to make this work in principle, because nothing obligates you to
insert the same thing into column i as column j or k -- you've merely
done it that way this one time.
Inference is clever enough to not differentiate based on irrelevant
factors like column ordering among available, equivalent unique
indexes. It's already very sophisticated for a mechanism that's just
there to handle edge cases. I don't see a need for it to become more
sophisticated.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-17 19:24:08 | Re: ALTER INDEX ... ALTER COLUMN not present in dump |
Previous Message | Tom Lane | 2018-12-17 14:50:16 | Re: BUG #15554: Broken pipe when doing a COPY of a parallel query |