Re: possible bug in DB/pgsql.php

fabrizio.ermini@sysdat.it wrote: > > On 19 Feb 2001, at 13:27, Stig S. Bakken wrote: > > > fabrizio.ermini@sysdat.it wrote: > > > > > > Hmm, maybe I'm straying too far...I'm not too content of my own > > > suggestions. Your turn... > > > > I've implemented your suggestion now and added a transaction test for > > pgsql as well. Could you give it a shot and see if it solves your > > problem? > > > > Funny to see that you've liked my suggestions more than myself :-) > I'll sure do it this afternoon, after "regular" work time :-)... > > > One thing I noticed is that postgres shows the changes done inside a > > transaction to other transactions before it is committed. With other > > databases the changes are not visible until you do a commit. This one > > is a bit hard to emulate though. > > > This has to do with the particular level of isolation the DB > implements. PGsql works at 2 possible isolation levels: read > committed, and serializable isolation (you can switch any time with > a SET command). The first mode, that's the default one (and very > few users change it IMHO) allows unrepeatable reads, that is, in > short: querys inside a transaction can read uncommitted data from > other transactions. In the second mode, this is not possible > (updates are not shown to other transactions until committed). > > I do not see why you could wish to "emulate" this, however; I think > it's wiser to let each backend handle transaction its own way. I > would leave to the programmer the task to decide if he needs read > committed or serializable isolation level. > > If you wish to achieve the maximum compatibility between various > backends, guess the smarter thing it's relying on SQL92 > standards. They consider, indeed, the serializable level as the > default. Since it's switchable at runtime, PG could be made to run > at that level "by default" under PEAR simply by issuing the "SET > LEVEL..." in the constructor; in this case, for the user that wish to > use the "relaxed" level, there is still the possibility to switch back > using the reversed command. We'd just to be sure that PG users > migrating to PEAR are aware of this "reversed default", writing it at > capital letters in every piece of doc we can (not that there are > much, but... :-)), or they could be a little confused! > > I'll continue later... Hi Fabrizio, I was only joking about emulating. :-) IMHO the "transaction visibility" issue is something to just keep on the radar for now. We may want to do something about it later after testing if it _is_ possible to set up a consistent behaviour in all databases that support transactions. - Stig