Re: UPSERT

Hannu Krosing <hannu@skype.net>

From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Jonathan Scher <js@oxado.com>, pgsql-hackers@postgresql.org
Date: 2007-03-04T12:55:47Z
Lists: 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