Re: Identity projection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: hlinnaka(at)iki(dot)fi, "'Kyotaro HORIGUCHI'" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Identity projection
Date: 2013-02-08 17:36:47
Message-ID: 20033.1360345007@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
> As per my understanding, currently in code wherever Result node can be
> avoided,
> it calls function is_projection_capable_plan(), so we can even enhance
> is_projection_capable_plan()
> so that it can also verify the expressions of tlists. But for this we need
> to change at all places
> from where is_projection_capable_plan() is called.

Hm. Really there's a whole dance that typically goes on, which is like

if (!is_projection_capable_plan(result_plan))
{
result_plan = (Plan *) make_result(root,
sub_tlist,
NULL,
result_plan);
}
else
{
/*
* Otherwise, just replace the subplan's flat tlist with
* the desired tlist.
*/
result_plan->targetlist = sub_tlist;
}

Perhaps we could encapsulate this whole sequence into a function called
say assign_targetlist_to_plan(), which would have the responsibility to
decide whether a Result node needs to be inserted.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Kretschmer 2013-02-08 17:37:45 Re: Bug, Feature, or what else?
Previous Message Andrew Dunstan 2013-02-08 17:31:28 Re: Time for an autoconf update