From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Jacob <jacob(at)internet24(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Updating row with updating function, bug or feature? |
Date: | 2009-09-30 14:17:18 |
Message-ID: | 14350.1254320238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thomas Jacob <jacob(at)internet24(dot)de> writes:
> I've run into some weirdness in PSQL 8.3.8 (Ubuntu 8.04 LTS x86_64
> package). When I update a row while using a function result
> that updates that very same row in the "WHERE" part of the update,
> the main update no longer takes place, even though the "WHERE"
> conditions should match. But if I execute
> the function before the update, and then do the update
> based on the same logic, I see both changes.
This is expected; it's worked like that since Berkeley days.
An UPDATE will not touch a row that's already been updated
within your own transaction since the UPDATE started. This
is mainly to avoid sorceror's-apprentice syndrome with repeatedly
updating the same row.
In general, having side-effects in a function invoked in WHERE
is a dangerous and unwise practice anyhow, IMNSHO. You have
very little control over when or even whether the side effects
will happen.
In the particular case at hand, you might want to think about
using SELECT FOR UPDATE locking instead of rolling your own.
Something like
BEGIN;
SELECT * FROM tab WHERE id = x FOR UPDATE;
... do some work using retrieved values ...
UPDATE tab SET ... WHERE id = x;
COMMIT;
has simple and reliable behavior.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2009-09-30 14:43:16 | Re: ms-sql -> pg 8.x |
Previous Message | Tom Lane | 2009-09-30 13:55:55 | Re: Where can I get the number of plans that considered by Planner? |