From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible problem in Custom Scan API |
Date: | 2017-04-11 20:58:49 |
Message-ID: | 4509.1491944329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> writes:
>> 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*.
Uh, no, construction of a custom plan node is entirely driven by the
PlanCustomPath method as far as I can see. You're free to ignore what
create_scan_plan did and insert your own tlist. In particular, if what
your custom path actually is is a rescan of something like an
IndexOnlyScan, why don't you just copy the IOS's result tlist?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-04-11 21:16:16 | Re: TAP tests take a long time |
Previous Message | Tom Lane | 2017-04-11 20:51:03 | Re: src/interfaces/libpq shipping nmake-related Makefiles |