Skip site navigation (1) Skip section navigation (2)

Re: BUG #1231: Probelm with transactions in stored code.

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1231: Probelm with transactions in stored code.
Date: 2004-08-27 18:24:54
Message-ID: 412F7C76.6020702@bigfoot.com (view raw or flat)
Thread:
Lists: pgsql-bugs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Treat wrote:

| On Thu, 2004-08-26 at 09:08, Gaetano Mendola wrote:
|
|>Robert Treat wrote:
|>
|>
|>>On Thu, 2004-08-26 at 04:23, Gaetano Mendola wrote:
|>>
|>>
|>>>Tom Lane wrote:
|>>>
|>>>
|>>>>Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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.
|>>>
|>>
|>>I don't think this was ever considered a feature (at least I never found
|>>any evidence of that) but more the concern was that it was "expected
|>>behavior" and changing that behavior might toss people into a loop who
|>>were expecting it.
|>
|>Yes, I used the wrong expression is not a feature but a gotcha.
|>I fairly trust that someone is currently using this behaviour considering it
|>the good expected one.
|>
|
|
| Really? I don't.  I do suspect there are people using this behavior
| considering it the bad, but expected, one.  However if people really do
| want this functionality to stay the same, let them speak up via a vote
| on the subject.

A vote ? What do you expect from this question:

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

shall return one or two given id primary key for the table "test"?


I hope that 100% will reply: one.


Regards
Gaetano Mendola



















-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBL3x17UpzwH2SGd4RArKIAKDU4rnhxt9GK7HL0Kjn0xzbPGHuvwCgkqtl
H1aLZ6j4CRnJD1S2cJ0Uf+A=
=yvUK
-----END PGP SIGNATURE-----


In response to

pgsql-bugs by date

Next:From: Gaetano MendolaDate: 2004-08-27 18:31:30
Subject: Re: BUG #1231: Probelm with transactions in stored code.
Previous:From: Robert TreatDate: 2004-08-27 17:34:42
Subject: Re: BUG #1231: Probelm with transactions in stored code.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group