On Fri, 2004-04-16 at 00:17, Tom Lane wrote:
> "Uwe C. Schroeder" <[EMAIL PROTECTED]> writes:
> > On Thursday 15 April 2004 04:20 pm, Tom Lane wrote:
>
> If we were to advance the QuerySnaphot between statements of a plpgsql
> function, the problem would go away because the SELECT would see
> tra
Robert Treat <[EMAIL PROTECTED]> writes:
> On Fri, 2004-04-16 at 00:17, Tom Lane wrote:
>> Now in this situation it is good to recognize the effects of other
>> transactions between statements of a plpgsql function, but it's not hard
>> to think up cases in which plpgsql functions would break if th
"Uwe C. Schroeder" <[EMAIL PROTECTED]> writes:
> On Thursday 15 April 2004 04:20 pm, Tom Lane wrote:
>> ... The problem is that the SELECT
>> doesn't get the right result. The SELECT actually sees two row versions
>> as being valid: the one you just created by UPDATE, and whichever one
>> was curr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 15 April 2004 04:20 pm, Tom Lane wrote:
> "Uwe C. Schroeder" <[EMAIL PROTECTED]> writes:
> > I use a stored proc to get the next identifier:
> >
> > CREATE OR REPLACE FUNCTION ib_nextval (character varying) RETURNS
> > character varying
> >
