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 loggi
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
> > un
> 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 t
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
: 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 '
> clause results in the cursor name being placed in the UpdateStmt
-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 try
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
>
H
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"
"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 m
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 ’
> >> clause results in the cursor name being placed in the UpdateStmt or
> >
"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 â
>> clause results in the cursor name being placed in the UpdateStmt or
>> DeleteStmt structure. During the processing of the func
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 ..
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
> In the UPDATE or DELETE statements the ‘WHERE CURRENT OF ’
> clause results in the cursor name being placed in the UpdateStmt or
> DeleteStmt structure. During the processing of the functions -
> transformDeleteStmt() and transformUpda
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
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
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 h
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:
> 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
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 prop
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 HeapTupleSatisf
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 upda
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
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 b
> -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 me
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 t
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
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 i
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 ext
> -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 P
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
> -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 i
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
Bruce Momjian wrote:
(B>
(B> Hiroshi Inoue wrote:
(B> > Bruce Momjian wrote:
(B> > >
(B> > > Peter Eisentraut wrote:
(B> > > > Bruce 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
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
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 mo
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 tabl
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> READO
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/INSENSITIVEp
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
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 of FOR UPDATE with or without a name list> is specified, then I
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 of FOR UPDATE with or without a is specified, then INSENSITIVE shall not be specified and QE
shall
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 al
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
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 tha
44 matches
Mail list logo
