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
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
42 matches
Mail list logo
