Re: UPSERT strange behavior - Mailing list pgsql-hackers

From Tom Lane
Subject Re: UPSERT strange behavior
Date
Msg-id 19174.1472150971@sss.pgh.pa.us
Whole thread Raw
In response to Re: UPSERT strange behavior  (Peter Geoghegan <pg@heroku.com>)
Responses Re: UPSERT strange behavior  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> On Thu, Aug 25, 2016 at 7:12 AM, Ivan Frolkov <ifrol2001@mail.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: increasing the default WAL segment size
Next
From: Tom Lane
Date:
Subject: Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()