| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: updateable cursors & visibility |
| Date: | 2003-04-02 14:58:51 |
| Message-ID: | 20950.1049295531@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> 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 HeapTupleSatisfies() or some of the logic there in to do
> this.
I don't think so; you'll need to use EvalPlanQual. This is not
different from the situation where a regular UPDATE finds a tuple that is
not the latest version of its row.
Should I point out that we already have semantics for that behavior, and
they depend on the serialization mode? Most of this discussion seems to
completely ignore the MVCC semantics we already have for updates/deletes
applied to rows that aren't current anymore. ISTM we should stick to
that behavior ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Liu | 2003-04-02 15:10:51 | Re: 7.3.2 make failed on AIX4.3 using native c compiler |
| Previous Message | Gavin Sherry | 2003-04-02 14:52:54 | Re: updateable cursors & visibility |