* Albe Laurenz:
> The original question asked was "how can I tell an error that is caused
> by incomplete isolation from another error?"
>
> If you have a code segment like
>SELECT COUNT(id) INTO i2 FROM a WHERE id = i;
>IF i2 = 0 THEN
> INSERT INTO a (id) VALUES (i);
>END IF;
>
* Craig Ringer:
> The test program, attached, demonstrates what I should've known in the
> first place. In SERIALIZABLE isolation, the above is *guaranteed* to
> fail every time there's conflict, because concurrent transactions cannot
> see changes committed by the others. So is a SELECT test then
Craig Ringer wrote:
> > The drawback is that some of the side effects of the INSERT occur
> > before the constraint check fails, so it seems to me that I still need
> > to perform the select.
>
> If you really can't afford the INSERT side effects and can't redesign
> your code to be tolerant of th
On Thu, 2009-07-16 at 14:13 +, Florian Weimer wrote:
> The drawback is that some of the side effects of the INSERT occur
> before the constraint check fails, so it seems to me that I still need
> to perform the select.
I was about to foolishly suggest:
Instead of:
SELECT 1 FROM x WHERE a = 4
* Albe Laurenz:
>SELECT COUNT(id) INTO i2 FROM a WHERE id = i;
>IF i2 = 0 THEN
> /* This INSERT will never throw an exception if the
> transactions are truly serialized */
> INSERT INTO a (id) VALUES (i);
> RETURN TRUE;
>ELSE
> RETURN FALSE;
>END IF
Florian Weimer wrote:
> SERIALIZABLE isolation level doesn't really conform to the spec
> because it doesn't deal with phantoms. The only case I've come across
> where this actually matters is when you're implementing some sort of
> "insert into table if not yet present" operation. This will typi
