Re: UPSERT - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: UPSERT
Date
Msg-id 1173012947.3132.6.camel@localhost.localdomain
Whole thread Raw
In response to Re: UPSERT  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UPSERT  (Bruno Wolff III <bruno@wolff.to>)
Re: UPSERT  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Ühel kenal päeval, R, 2007-03-02 kell 10:13, kirjutas Tom Lane:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > My instinct would be to follow your first strategy, i.e. detect which 
> > path is needed rather than try one and then if it fails do the other.
> 
> The very first thing you need to think about is how to solve the race
> condition problem, ie, two backends concurrently trying to insert
> identical data.  

Then one of them will update the data inserted by whoeved got the insert
first.

> Until you have a plausible mechanism for that, the
> whole thing is pie-in-the-sky.

Is'nt the standard way of doing it thus:

UPDATE
IF NOT FOUND THEN  INSERT IF DUPLICATE KEY THEN   UPDATE END IF
END IF

At least this is how UPSERT is usually done in plpgsql


-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Synchronized Scan update
Next
From: Bruno Wolff III
Date:
Subject: Re: UPSERT