On Wed, 24 Jan 2007, John Bartlett wrote:
[regarding optional DBA/SysAdmin logging of Updateable Cursors]
I can see where you are coming from but I am not sure if a new log entry
would be such a good idea. The result of creating such a low level log could
be to increase the amount of logging
On Wed, 2007-01-24 at 14:54 +1100, John Bartlett wrote:
The reason for those 5 options is to consider different means to cover the
Prepared Stmt requirement where the different stages of processing are
actually in different transactions.
John,
Thanks for explaining.
Wow! I've never come
That is also the safe thing to do, since PostgreSQL's implementation
of
WITH HOLD cursors doesn't leave the rows locked. That can lead to the
rows being deleted from under the cursor, for which the standard is
unclear as to whether that is acceptable, or not.
Um, the default use case is to
On Wed, 2007-01-24 at 14:27 +0100, Zeugswetter Andreas ADI SD wrote:
That is also the safe thing to do, since PostgreSQL's implementation
of
WITH HOLD cursors doesn't leave the rows locked. That can lead to the
rows being deleted from under the cursor, for which the standard is
unclear as
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
In the UPDATE or DELETE statements the ‘WHERE CURRENT OF cursor_name’
clause results in the cursor name being placed in the UpdateStmt or
DeleteStmt structure. During the processing of the functions -
transformDeleteStmt() and
Joshua D. Drake wrote:
Lukas Kahwe Smith wrote:
Joshua D. Drake wrote:
Great! I will put it on my, Remember to bug Arul list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
Sure if you bother to unlock the page for me ;)
hmm ..
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
In the UPDATE or DELETE statements the âWHERE CURRENT OF cursor_nameâ
clause results in the cursor name being placed in the UpdateStmt or
DeleteStmt structure. During the processing of the
On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
In the UPDATE or DELETE statements the ‘WHERE CURRENT OF cursor_name’
clause results in the cursor name being placed in the UpdateStmt or
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
This really isn't gonna work, because it assumes that the tuple that is
current at the instant of parsing is still going to be current at
execution time.
Of course thats true, but you've misread my
On Tue, 2007-01-23 at 10:39 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
This really isn't gonna work, because it assumes that the tuple that is
current at the instant of parsing is still going to be current at
execution
On Wed, 24 Jan 2007, FAST PostgreSQL wrote:
We are trying to develop the updateable cursors functionality into
Postgresql. I have given below details of the design and also issues we are
facing. Looking forward to the advice on how to proceed with these issues.
Rgds,
Arul Shaji
Hi Arul,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Troy
Sent: Wednesday, 24 January 2007 4:37 AM
To: FAST PostgreSQL
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Updateable cursors
On Wed, 24 Jan 2007, FAST PostgreSQL wrote:
We are trying to develop
To: FAST PostgreSQL
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Updateable cursors
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
In the UPDATE or DELETE statements the 'WHERE CURRENT OF cursor_name'
clause results in the cursor name being placed in the UpdateStmt or
DeleteStmt
We are trying to develop the updateable cursors functionality into
Postgresql. I have given below details of the design and also issues we are
facing. Looking forward to the advice on how to proceed with these issues.
Rgds,
Arul Shaji
1. Introduction
--
This is a combined
FAST PostgreSQL wrote:
We are trying to develop the updateable cursors functionality into
Postgresql. I have given below details of the design and also issues we are
facing. Looking forward to the advice on how to proceed with these issues.
Rgds,
Arul Shaji
Would this be something that
On Tue, 23 Jan 2007 15:48, Joshua D. Drake wrote:
FAST PostgreSQL wrote:
We are trying to develop the updateable cursors functionality into
Postgresql. I have given below details of the design and also issues we
are facing. Looking forward to the advice on how to proceed with these
FAST PostgreSQL wrote:
On Tue, 23 Jan 2007 15:48, Joshua D. Drake wrote:
FAST PostgreSQL wrote:
We are trying to develop the updateable cursors functionality into
Postgresql. I have given below details of the design and also issues we
are facing. Looking forward to the advice on how to
Joshua D. Drake wrote:
Great! I will put it on my, Remember to bug Arul list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
I will try to find some time during this week (likely on the weekend) to
also try and figure out if these
Lukas Kahwe Smith wrote:
Joshua D. Drake wrote:
Great! I will put it on my, Remember to bug Arul list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
Sure if you bother to unlock the page for me ;)
I will try to find some
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:
(B
(B Peter Eisentraut [EMAIL PROTECTED] writes:
(B Hiroshi Inoue writes:
(B Must a SENSITIVE cursor see other applications' changes made
(B while the cursor is open ?
(B Yes. It is immaterial whether the change came from a different
(B 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:
(B
(B Peter Eisentraut wrote:
(B Bruce Momjian writes:
(B
(B One idea is to require FOR UPDATE on the cursor --- while that prevents
(B other transactions from changing the cursor, it doesn't deal with the
(B 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:
(B
(B Hiroshi Inoue wrote:
(B Bruce Momjian wrote:
(B
(B Peter Eisentraut wrote:
(BBruce Momjian writes:
(B
(B
(B I don't understand what you two are discussing.
(B What's is SENSITIVE, INSENSITIVE or ASESNSITIVE ?
(B
(B In SQL99 standard, I see:
Bruce Momjian wrote:
(B
(B Sorry, no idea. Peter's idea is that FOR UPDATE requires SENSITIVE, so
(B INSENSITIVE has to be READONLY because the update has to see other
(B changes to be accurate.
(B
(B I think clearly SENSITIVE/READONLY should be possible, so:
(B
(B
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:
(B
(B Folks,
(B
(B I'd like to implement updateable cursors. I'll be working on just
(B getting updateable cursors working for relatively simple SELECT queries
(B (e.g. no joins, aggregates, grouping, user-defined function calls,
(B 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
44 matches
Mail list logo
