From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Why is unique constraint needed for upsert? |
Date: | 2014-07-23 18:40:05 |
Message-ID: | 22949.1406140805@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John R Pierce <pierce(at)hogranch(dot)com> writes:
> On 7/23/2014 10:21 AM, Seamus Abshere wrote:
>> Upsert is usually defined [1] in reference to a violating a unique key:
>> Is this theoretically preferable to just looking for a row that
>> matches certain criteria, updating it if found or inserting otherwise?
> what happens when two connections do this more or less concurrently, in
> transactions?
For the OP's benefit --- the subtext John left unstated is that the
unique-key mechanism has already solved the problem of preventing
concurrent updates from creating duplicate keys. If we build a version of
UPSERT that doesn't rely on a unique index then it'll need some entirely
new mechanism to prevent concurrent key insertion. (And if you don't care
about concurrent cases, you don't really need UPSERT ...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | klo uo | 2014-07-23 19:33:21 | Re: question about memory usage |
Previous Message | Francisco Olarte | 2014-07-23 18:03:02 | Re: Referencing serial col's sequence for insert |