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
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 |