Re: Updateable cursors

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "FAST PostgreSQL" <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updateable cursors
Date: 2007-01-23 15:31:21
Message-ID: 1169566281.3776.559.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> 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 functions -
> >> transformDeleteStmt() and transformUpdateStmt() - the cursor name is used to
> >> obtain a pointer to the related Portal structure
>
> > To support prepared statements we'd need to do this name lookup just
> > once, so that the Update/Delete stmt can record which Portal to look at
> > for the current tuple.
>
> 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 comment.

The portal with the cursor in will not change, no matter how many times
we execute WHERE CURRENT OF in another portal. The OP suggested putting
the current tuple pointer onto the portal data, so this will work.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-01-23 15:32:58 Re: [HACKERS] Win32 WEXITSTATUS too
Previous Message Tom Lane 2007-01-23 15:31:12 Re: [HACKERS] Win32 WEXITSTATUS too