On Thursday, March 14, 2013 8:35 PM Tom Lane wrote:
> I'm starting to review this patch now, and I'm having a hard time with
> this particular design decision:
>
> Amit Kapila <amit.kap...@huawei.com> writes:
> > We cannot directly compare expressions in target list as even if
> expressions
> > are equal, below node (ex. APPEND) will
> > not do projection, and hence expr will not be evaluated.
>
> I think this is nonsense. Whatever the tlist of the lower node is,
> that
> is supposed to describe what it's going to return. That node might not
> be able to do projection, but that doesn't mean that something
> underneath it didn't. So I think this patch is missing a bet by not
> accepting equal() expressions. Did you have a test case showing that
> this wouldn't work?
I have missed the point that lower nodes would have done the expression
evaluation during projection.
But I think before your checkin, below comment in grouping planner might be
misleading:
/*
* If the top-level plan node is one that
cannot do expression
* evaluation, we must insert a Result node
to project the
* desired tlist.
*/
Now because top-level node cannot do expression evaluation, but some lower
node would have done it.
Here the need seems to be only in case when the top-level plan node tlist is
not desired tlist.
Why do we need expression evaluation inside comment?
With Regards,
Amit Kapila.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
