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

Re: [HACKERS] cursors in LLL

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] cursors in LLL
Date: 1998-10-06 02:07:18
Message-ID: 36197B56.3949B470@krs.ru (view raw or flat)
Thread:
Lists: pgsql-hackers
Hiroshi Inoue wrote:
> 
> Hi all.
> I'm looking forward to the appearance of LLL in PostgreSQL 6.5 and have a
> question about the sensitivity of cursors in LLL.
> 
> In LLL cursors are INSENSITIVE as Oracle ?
> 
> Currently cursors are indeterminate and in some cases they are strangely
> sensitive(for me).

Do you mean seeing row inserted between fetches ?
Should this be changed ?
How is this in Oracle, Informix, Sybase, standards ?

> In LLL the behavior of cursors will be more complicated, if changes by other
> transactions can be seen by fetch statements(especially for read committed
> isolation level).
> 
> I hope INSENSITIVE cursors to be implemented whose behavior we can predict
> and I think that they can be realized according to proposals for LLL by
> Vadim.
> 
> In LLL access methods return snapshot of data as they were in _some_ point
> in time.
> For read committed mode this moment is the time when statement began.
> For serializable mode this is the time when current transaction began.
> 
> For a INSENSITIVE cursor this is the time when it was opened(declared),
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is easy to implement.
But I'd like to know what standards say about cursor sensitivness...

> not the time when the fetch statements for it began ?

Thanks.

Vadim

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-10-06 02:23:13
Subject: Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
Previous:From: Tatsuo IshiiDate: 1998-10-06 02:05:56
Subject: Re: [HACKERS] Open 6.4 items

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