| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| 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 14:55:17 |
| Message-ID: | 18474.1169564117@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2007-01-23 14:55:34 | Re: msvc failure in largeobject regression test |
| Previous Message | Tom Lane | 2007-01-23 14:37:59 | Re: Free space management within heap page |