From: | Ted Byers <r(dot)ted(dot)byers(at)rogers(dot)com> |
---|---|
To: | Vivek Khera <khera(at)kcilink(dot)com>, Colin Wetherbee <cww(at)denterprises(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: SQL design pattern for a delta trigger? |
Date: | 2007-12-10 22:48:46 |
Message-ID: | 528829.80785.qm@web88304.mail.re4.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
--- Vivek Khera <khera(at)kcilink(dot)com> wrote:
>
> On Dec 10, 2007, at 5:04 PM, Colin Wetherbee wrote:
>
> > For what it's worth, the real algorithm would be
> as follows. I
> > hadn't had enough coffee yet, and I forgot the
> UPDATE bit.
> >
> > IF
> > (a query matching your old data returns rows)
> > THEN
> > UPDATE with your new data
> > ELSE
> > INSERT your new data
>
> Still exists race condition. Your race comes from
> testing existence,
> then creating/modifying data afterwards. You need
> to make the test/
> set atomic else you have race.
>
Yes, but how do you do that in a stored function or
procedure or in a trigger. It would be obvious to me
if I were writing this in C++ or Java, but how do you
do it using SQL in an RDBMS?
I saw something about table locks, but that doesn't
seem wise, WRT performance.
The classic example of a race condition, involving a
bank account, was used in the manual to introduce the
idea of a transaction, but we can't use a transaction
in a trigger, can we?
It is one thing to point out a race condition, but a
pointer to a solution that would work in the context
of the problem at hand would be useful and
appreciated.
Thanks all.
Ted
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2007-12-10 22:57:11 | Re: SQL design pattern for a delta trigger? |
Previous Message | Tom Lane | 2007-12-10 22:29:44 | Re: partitioned table query question |