On Wed, 31 Jan 2018 21:12:51 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yugo Nagata <nagata@sraoss.co.jp> writes:
> > I'm sorry the patch attached in the previous mail is broken and
> > not raises a compile error. I attached the fixed patch.
>
> This patch is almost certainly wrong: you can't assume that the scan-level
> state matches the tuple we are currently processing at top level. Any
> sort of delaying action, for instance a sort or materialize node in
> between, would break it.
In execCurrentOf(), when FOR UPDATE is not used, search_plan_tree() searches
through the PlanState tree for a scan node and if a sort or materialize node
(for example) is found it fails with the following error.
ERROR cursor xxx is not a simply updatable scan of table yyy
So, I think what you concern would not occur by the patch as well as the orginal
code. However, I may be missing something. Could you explain more about this if so?
>
> We need to either fix this aspect:
>
> >> IndexOnlyScan returns a virtual tuple that doesn't have system
> >> column, so we can not get ctid in the same way of other plans.
>
> or else disallow using IndexOnlyScan when the ctid is needed.
CURRENT OF is used after the scan is executed and a tuple is fetched,
so we can't know whether the ctid is needed or not in advance in this
case. We can raise an error message when CURRENT OF is used
for IndexOnlyScan plan, though.
Regards,
>
> regards, tom lane
--
Yugo Nagata <nagata@sraoss.co.jp>
