On Mon, 31 Mar 2003, Peter Eisentraut wrote:
Tom Lane writes:
Serializable or not, there is a good case for saying that cursors don't
see changes made after they are opened, period.
No one disputes that insensitive cursors are a valid concept. But this
discussion is about updating
Gavin Sherry [EMAIL PROTECTED] writes:
Regardless of which, we could insert a special case in ExecutePlan() (or
somewhere more appropriate?) to test that the tuple returned from the
lower level ExecTidScan() still satisifies the cursor query. It should be
sufficient to use HeapTupleSatisfies()
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Hiroshi Inoue kirjutas E, 31.03.2003 kell 03:40:
2) dynamic
It can detect any changes made to the membership, order,
and values of the result set after the cursor is opened.
What would it mean in
Hiroshi Inoue kirjutas E, 31.03.2003 kell 03:40:
Tom Lane wrote:
Serializable or not, there is a good case for saying that cursors don't
see changes made after they are opened, period. The current
implementation locks down the cursor's snapshot at DECLARE time.
It's only because
Hiroshi Inoue kirjutas E, 31.03.2003 kell 19:08:
-Original Message-
From: Hannu Krosing [mailto:[EMAIL PROTECTED]
Hiroshi Inoue kirjutas E, 31.03.2003 kell 03:40:
2) dynamic
It can detect any changes made to the membership, order,
and values of the result set
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Hiroshi Inoue writes:
Must a SENSITIVE cursor see other applications' changes made
while the cursor is open ?
Yes. It is immaterial whether the change came from a different
application or the same one.
Peter Eisentraut [EMAIL PROTECTED] writes:
Hiroshi Inoue writes:
Must a SENSITIVE cursor see other applications' changes made
while the cursor is open ?
Yes. It is immaterial whether the change came from a different
application or the same one.
Nevertheless, the cursor sensitivity does not
Hiroshi Inoue writes:
Must a SENSITIVE cursor see other applications' changes made
while the cursor is open ?
Yes. It is immaterial whether the change came from a different
application or the same one.
Nevertheless, the cursor sensitivity does not excuse you from observing
the transaction
Hiroshi Inoue wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Hiroshi Inoue wrote:
If the cursor is INSENSITIVE, it mustn't see the row ?
Right.
If so, isn't the difference between SENSITIVE and INSENSITIVE extreme ?
Yes.
Why
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Hiroshi Inoue wrote:
I don't understand what you two are discussing.
What's is SENSITIVE, INSENSITIVE or ASESNSITIVE ?
In SQL99 standard, I see:
- If the cursor is insensitive, then
Hiroshi Inoue wrote:
If the cursor is INSENSITIVE, it mustn't see the row ?
Right.
If so, isn't the difference between SENSITIVE and INSENSITIVE extreme ?
Yes.
Why do you or Peter refer to ASENSITIVE little ?
Not sure --- ASENSITIVE seems to be do whatever you want, which is
always
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Hiroshi Inoue wrote:
If the cursor is INSENSITIVE, it mustn't see the row ?
Right.
If so, isn't the difference between SENSITIVE and INSENSITIVE extreme ?
Yes.
Why do you or Peter refer to
Hiroshi Inoue wrote:
I don't understand what you two are discussing.
What's is SENSITIVE, INSENSITIVE or ASESNSITIVE ?
In SQL99 standard, I see:
- If the cursor is insensitive, then significant changes are not
visible.
- If the cursor is
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
One idea is to require FOR UPDATE on the cursor --- while that prevents
other transactions from changing the cursor, it doesn't deal with the
current transaction modifying the table outside the
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
One idea is to require FOR UPDATE on the cursor --- while that prevents
other transactions from changing the cursor, it doesn't deal with the
current transaction modifying the table
Hiroshi Inoue,
But still can't explain this:
SENSITIVE = not READ_ONLY
It's in the ODBC Spec.
Bruce Momjian wrote:
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
I don't understand what you two are discussing.
What's is SENSITIVE, INSENSITIVE or ASESNSITIVE ?
In SQL99 standard, I see:
Bruce Momjian wrote:
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see other
changes to be accurate.
I think clearly SENSITIVE/READONLY should be possible, so:
Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
INSENSITIVE has to be READONLY because the update has to see other
changes to be accurate.
I think clearly SENSITIVE/READONLY should be possible, so:
READONLY/SENSITIVE possible
READONLY/INSENSITIVE
Hello Neil,
I try example for Oracle jdbc 1.4 driver
This is sample and results.
I hope that is helps.
If you want yet another example, please tell me.
regards
Haris Peco
/**
* A simple sample to check the availability of scrollable result sets.
*
* Please use jdk1.2 or later version
Folks,
I'd like to implement updateable cursors. I'll be working on just
getting updateable cursors working for relatively simple SELECT queries
(e.g. no joins, aggregates, grouping, user-defined function calls,
etc.). BTW, I believe that's all the SQL spec requires, but I need to
double check
Neil Conway [EMAIL PROTECTED] writes:
- if the user updates a row X in the cursor, then rewinds the cursor and
fetches X again, should they see the new X or the old X?
If it's considered an insensitive cursor, I'd think it should see the
old X. You would have a hard time making the code do
Neil Conway wrote:
On Mon, 2003-03-24 at 22:50, Hiroshi Inoue wrote:
Does the SQL standard allow INSENSITIVE updatable cursors ?
Hmmm... apparently not:
(Subsection 14.1, Syntax Rules of DECLARE CURSOR)
11) If an updatability clause of FOR UPDATE with or without a column
name list is
Neil Conway wrote:
Folks,
I'd like to implement updateable cursors. I'll be working on just
getting updateable cursors working for relatively simple SELECT queries
(e.g. no joins, aggregates, grouping, user-defined function calls,
etc.). BTW, I believe that's all the
On Mon, 2003-03-24 at 22:50, Hiroshi Inoue wrote:
Does the SQL standard allow INSENSITIVE updatable cursors ?
Hmmm... apparently not:
(Subsection 14.1, Syntax Rules of DECLARE CURSOR)
11) If an updatability clause of FOR UPDATE with or without a column
name list is specified, then INSENSITIVE
25 matches
Mail list logo
