Re: BUG #1231: Probelm with transactions in stored code. - Mailing list pgsql-bugs

From Gaetano Mendola
Subject Re: BUG #1231: Probelm with transactions in stored code.
Date
Msg-id 412D9E05.9070408@bigfoot.com
Whole thread Raw
In response to Re: BUG #1231: Probelm with transactions in stored code.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #1231: Probelm with transactions in stored code.
List pgsql-bugs
Tom Lane wrote:

 > Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
 >
 >>I believe it sees the one that was valid in the snapshot as of the
 >>beginning of the function.
 >
 >
 > Actually, the problem is that it can see *both* that row and the updated
 > row; it's a crapshoot which one will be returned by the SELECT INTO.

Confirmed, if the last select is:

select count(*) into a from test where id=1;

this return 2. There is a space for a new bug considering that if the
table have the unique index on id that select must return 1.

 > The reason this can happen is that we're not doing SetQuerySnapshot
 > between commands of a plpgsql function.  There is discussion going way
 > way back about whether we shouldn't do so (see the archives).  I think
 > the major reason why we have not done it is fear of introducing
 > non-backwards-compatible behavior.  Seems like 8.0 is exactly the right
 > version to consider doing that in.

If my 2 cents are valid I agree with you, what I don't totally agree is why
consider this bug as a *feature* in previous 8.0 version.


Regards
Gaetano Mendola

pgsql-bugs by date:

Previous
From: Ingo Schellhammer
Date:
Subject: MOVE FIRST does not work in PL/pgSQL on refcursor
Next
From: Robert Treat
Date:
Subject: Re: BUG #1231: Probelm with transactions in stored code.