Re: Why is unique constraint needed for upsert? (treat atomicity as optional)

From: Seamus Abshere <seamus(at)abshere(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Why is unique constraint needed for upsert? (treat atomicity as optional)
Date: 2014-07-23 21:15:32
Message-ID: 53D025F4.1010004@abshere.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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 as a (rigorously defined) option for
those who need it.

>>> -- no guarantees, no index required
>>> UPSERT age = 5 INTO dogs WHERE name = 'Jerry';
>
> and if there's several rows with name='Jerry', you'd want to update them
> ALL ? if name isn't indexed, this will, as Tom suggests, require a FULL
> table scan, and it still will have issues with concurrency

Ah, I was just saying, in terms of correctness, it seems to me that
upsert shouldn't NEED a index to work, just like you don't need an index
on "name" when you say WHERE name = 'Jerry' in SELECTs or INSERTS or
UPDATES.

Appreciate the defense of data integrity in any case!!

Best,
Seamus

--
Seamus Abshere, SCEA
https://github.com/seamusabshere

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G Johnston 2014-07-23 21:21:32 Re: Why is unique constraint needed for upsert? (treat atomicity as optional)
Previous Message John R Pierce 2014-07-23 21:03:12 Re: Why is unique constraint needed for upsert? (treat atomicity as optional)