Re: Clarification on a Time travel feature

There is one more condition under which this becomes useful. Suppose you
have requirements for setting transaction isolation level as serializable
only for select statements, you can avoid setting the transaction isolation
level as serializable by making use of this feature. any expert comments?

On 10/31/07, Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> wrote:
>
> There is only one condition under which this would be useful.
>
> Current Scenario:
>
> BEGIN
>
> Select x into var from inventory where y=const;
>
> update inventory..
>
> some more DMLs.
>
> some select into var2;
>
> if (condition based on var2)
> use the var;
>
> END;
>
> here i have to fire the first select query all the 100% of the time. Say
> if i have a feature to time travel within a transaction, i need to fire that
> select query on the probability of the condition based on var2 getting true.
>
>
> After that implementation
>
> BEGIN;
> store command id and increment it into cid;
> some DMLS
> some select into var2
> if(condition based on var2)
> select into :var as of cid;
>
> I know this is a small use-case. But if you think about it, the
> implementation is very easy. It wouldn't take much time to implement it.
>
> Thanks,
> Gokul.
>
>
>
>
>
>
>
> On 10/31/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com > wrote:
> >
> > Gokulakannan Somasundaram wrote:
> > > a) Is there a proposal in place for going back in time within a
> > transaction?
> >
> > Within a transaction? No, can't remember one. Doesn't sound very useful.
> >
> > --
> > Heikki Linnakangas
> > EnterpriseDB http://www.enterprisedb.com
> >
>
>
>
> --
> Thanks,
> Gokul.
> CertoSQL Project,
> Allied Solution Groups.
> (www.alliedgroups.com)
>

--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Groups.
(www.alliedgroups.com)