Tom Lane wrote:
> Reading between the lines, I think the problem may be that you're not
> being careful about how you set up custom_scan_tlist. But since the
> core code has zero involvement in that decision, it's hard to see why
> it would be a core code bug.
I'm sorry, but you didn't understand. It's *the core code* that builds the
targetlist, and sometimes it may decide to provide a physical targetlist,
not the one that's *really needed*. The broader targetlist has Vars that
cannot be supplied by the IndexOnlyScan node, hence the error.
We cannot come up with our own targetlist because we don't know if it's a
top node and we should return exactly the same tuple (CP_EXACT_TLIST) or
it's just the stray optimization that made us think so.
Append works only because it doesn't allow projections, and it can never
get a physical targetlist if an index doesn't contain all columns.
But everything changes when we use CustomScan: PostgreSQL will not pay
attention. For example, if our CustomScan is a child of NestLoop, the
former will call this (create_nestloop_plan):
inner_plan = create_plan_recurse(root, best_path->innerjoinpath, 0);
Since NestLoop can make projections, it doesn't enforce CP_EXACT_TLIST
flag, and our CustomScan may end up with a full physical targetlist (see
the code of create_scan_plan() if you don't believe me), INSTEAD OF the one
it really has been asked to produce. Meanwhile, Append will behave as it
should, since it doesn't care about physical tlists.
It's not just my imagination.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company