sri harsha writes:
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) .
Read the comment:
*reltargetlist - List of Var and PlaceHolderVar nodes for the values
*we need to output from this relation.
*
On Fri, Apr 29, 2016 at 11:12 AM, sri harsha
wrote:
>
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) . Can you shed some light on where the conversion
> from 141 to "original" attribute number takes place ??
>
If you try to print the node as *(No
On Fri, Apr 29, 2016 at 2:42 PM, sri harsha wrote:
>
> Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
> relation ( RelOptInfo) . Can you shed some light on where the conversion
> from 141 to "original" attribute number takes place ??
As Tom said, you must be looking at an O
Its not an OpExpr . It is a VAR , got it from "reltargetlist" in base
relation ( RelOptInfo) . Can you shed some light on where the conversion
from 141 to "original" attribute number takes place ??
Regards,
Harsha
On Fri, Apr 29, 2016 at 10:03 AM, Tom Lane wrote:
> sri harsha writes:
> >A
sri harsha writes:
>Assume the following query ,
> (SELECT a * 1 , b FROM TABLE_1) UNION ALL (SELECT a *1 , b FROM TABLE_2);
> In this query , attribute number of the VARs are 141 and 2 respectively !!
I doubt it.
Maybe you're looking at something that's not a Var, possibly an OpExpr,
but a
Hi,
Assume the following query ,
(SELECT a * 1 , b FROM TABLE_1) UNION ALL (SELECT a *1 , b FROM TABLE_2);
In this query , attribute number of the VARs are 141 and 2 respectively !!
What is the reason for this ??
I am trying to implement a FDW , so i need attribute numbers to fetch the
respe