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).
Bulk load
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
separating
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
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;
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 things like
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
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
