Tom Lane wrote:
I'm unimpressed by this part --- we couldn't back-patch such a change, and
I think it's unnecessary anyway in 9.6+ because the scan provider could
generate a nondefault pathtarget if it wants this to happen.
You're right, of course. Thank you very much!
--
Dmitry Ivanov
Postgr
Dmitry Ivanov writes:
> Tom Lane wrote:
>> I'm coming around to the idea that it'd be better to disable physical
>> tlists for custom scans.
>> However, I'm hesitant to make such a change in the back branches; if
>> there's anyone using custom scans who's negatively affected, they'd be
>> rightful
Tom Lane wrote:
I'm coming around to the idea that it'd be better to disable physical
tlists for custom scans.
I've been thinking about this all along, and it seems that this is a decent
decision. However, I've made a tiny bugfix patch which allows CustomScans
to notify the core code that the
Dmitry Ivanov writes:
>> 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.
> Are you sure? Even if it's true, this targetlist should still contain each
On Wed, Apr 12, 2017 at 12:59 AM, Dmitry Ivanov
wrote:
> Tom Lane wrote:
>
>> 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.
>>
>
> Are you sure? Even
Tom Lane wrote:
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.
Are you sure? Even if it's true, this targetlist should still contain each
and every Var t
Dmitry Ivanov 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
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'
Dmitry Ivanov writes:
> Tom Lane wrote:
>> Uh, why would you see that? The planner would never generate an
>> IndexOnlyScan in the first place if the query required any columns
>> not available from the index.
> True, but as you can see, create_append_plan() produces its own targetlist:
> stati
Tom Lane wrote:
Uh, why would you see that? The planner would never generate an
IndexOnlyScan in the first place if the query required any columns
not available from the index.
True, but as you can see, create_append_plan() produces its own targetlist:
static Plan *
create_append_plan(Planner
Dmitry Ivanov writes:
> In theory, CustomScans should be able to use any Plan nodes (i.e.
> 'custom_plans' list), but as far as I can understand, there's no way to
> override behavior of use_physical_tlist(), which means that we might see
> something like this:
> ERROR: variable not found in
11 matches
Mail list logo
