| From: | Hannu Krosing <hannu(at)skype(dot)net> |
|---|---|
| To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jonathan Scher <js(at)oxado(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: UPSERT |
| Date: | 2007-03-04 13:54:54 |
| Message-ID: | 1173016494.3132.12.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ühel kenal päeval, P, 2007-03-04 kell 07:46, kirjutas Bruno Wolff III:
> On Sun, Mar 04, 2007 at 14:55:47 +0200,
> Hannu Krosing <hannu(at)skype(dot)net> wrote:
> >
> > UPDATE
> > IF NOT FOUND THEN
> > INSERT
> > IF DUPLICATE KEY THEN
> > UPDATE
> > END IF
> > END IF
>
> I believe it is possible for the above to fail. For example another
> transaction could create a matching record between the update and insert
> and then another transaction could delete it between the insert and the
> second update.
Then we may do the second part as a loop and hope that eventually we hit
the right point with either INSERT or UPDATE:
UPDATE
WHILE NOT FOUND THEN
INSERT
IF DUPLICATE KEY THEN
UPDATE
END IF
END WHILE
--
----------------
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2007-03-04 15:06:05 | Re: UPSERT |
| Previous Message | Bruno Wolff III | 2007-03-04 13:46:58 | Re: UPSERT |