Re: [PHP-PEAR] possible bug in DB/pgsql.php

[email protected] wrote:
> 
> On 19 Feb 2001, at 13:27, Stig S. Bakken wrote:
> 
> > [email protected] 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