On 7/23/2014 3:58 PM, Seamus Abshere wrote:
Right - if you had a situation where that might happen, you would use
a slightly more advanced version of the UPSERT command (and/or add a
unique index).
a unique index wouldn't resolve the problem. without one, you'd end up
with two records, with
On 7/23/14 7:45 PM, John R Pierce wrote:
On 7/23/2014 3:29 PM, Seamus Abshere wrote:
My argument lives and dies on the assumption that UPSERT would be
useful even if it was (when given with no options) just a macro for
UPDATE db SET b = data WHERE a = key;
IF NOT found THEN
INSERT INTO
>
>
> hi David,
>
> My argument lives and dies on the assumption that UPSERT would be useful
> even if it was (when given with no options) just a macro for
>
> > UPDATE db SET b = data WHERE a = key;
> > IF NOT found THEN
> > INSERT INTO db(a,b) VALUES (key, data);
> > END IF;
>
> Adding
On 7/23/2014 3:29 PM, Seamus Abshere wrote:
My argument lives and dies on the assumption that UPSERT would be
useful even if it was (when given with no options) just a macro for
UPDATE db SET b = data WHERE a = key;
IF NOT found THEN
INSERT INTO db(a,b) VALUES (key, data);
END IF;
On 7/23/14 6:50 PM, David G Johnston wrote:
seamusabshere wrote
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 u
seamusabshere wrote
> 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
> se
seamusabshere wrote
>> At READ COMMITTED isolation level, you should always get an atomic insert
>> or update [1]
>
> I just think there are a lot of non-concurrent bulk loading and
> processing workflows that could benefit from the performance advantages
> of upsert (one trip to database).
Bul
