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
