From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Ivan Frolkov <ifrol2001(at)mail(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UPSERT strange behavior |
Date: | 2016-08-25 18:49:31 |
Message-ID: | 19174.1472150971@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Thu, Aug 25, 2016 at 7:12 AM, Ivan Frolkov <ifrol2001(at)mail(dot)ru> wrote:
>> So, if we have primary key and unique constraint on a table then upsert will
>> not work as would expected.
> Why is this unexpected?
> You only take the alternative path (UPDATE) in the event of a would-be
> duplicate violation. You can't upsert while using more than one index
> as an arbiter index. This is true unless they're more or less
> equivalent, in which case multiple arbiter indexes can be inferred,
> but that clearly doesn't apply here.
I think the point is that given the way he's set up the test case,
there should be no duplicate violation in the plain unique index
unless there is one in the arbiter index. So assuming that INSERT
tests the arbiter indexes first, there shouldn't be an error.
Maybe it doesn't do that, but it seems like it would be a good idea
if it did.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-25 19:06:27 | Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice() |
Previous Message | Robert Haas | 2016-08-25 17:51:25 | Re: increasing the default WAL segment size |