| 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: | Whole Thread | Raw Message | 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
| 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 |