hi all,
Upsert is usually defined [1] in reference to a violating a unique key:
Insert, if unique constraint violation then update; or update, if not found
then insert.
Is this theoretically preferable to just looking for a row that matches
certain criteria, updating it if found or
On 7/23/2014 10:21 AM, Seamus Abshere wrote:
hi all,
Upsert is usually defined [1] in reference to a violating a unique key:
Insert, if unique constraint violation then update; or update, if not
found then insert.
Is this theoretically preferable to just looking for a row that
matches
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of John R Pierce
Sent: Wednesday, July 23, 2014 1:32 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Why is unique constraint needed for upsert?
On 7/23/2014 10:21
John R Pierce pie...@hogranch.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?
On 7/23/14 3:40 PM, Tom Lane wrote:
John R Pierce pie...@hogranch.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
Seamus Abshere sea...@abshere.net writes:
On 7/23/14 3:40 PM, Tom Lane wrote:
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.
What if we treat atomicity as
On 7/23/2014 1:45 PM, Seamus Abshere wrote:
What if we treat atomicity as optional? You could have extremely
readable syntax like:
atomicity is not and never will be optional in PostgreSQL.
-- no guarantees, no index required
UPSERT age = 5 INTO dogs WHERE name = 'Jerry';
and if there's
On 7/23/14 6:03 PM, John R Pierce wrote:
On 7/23/2014 1:45 PM, Seamus Abshere wrote:
What if we treat atomicity as optional?
atomicity is not and never will be optional in PostgreSQL.
I'm wondering what a minimal definition of upsert could be - possibly
separating concurrency handling out
