Re: BUG #1231: Probelm with transactions in stored code.
От | Gaetano Mendola |
---|---|
Тема | Re: BUG #1231: Probelm with transactions in stored code. |
Дата | |
Msg-id | 412F7C76.6020702@bigfoot.com обсуждение исходный текст |
Ответ на | Re: BUG #1231: Probelm with transactions in stored code. (Robert Treat <xzilla@users.sourceforge.net>) |
Список | 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@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. |>>> |>> |>>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-----
В списке pgsql-bugs по дате отправления: