Re: [HACKERS] UNION ALL - Var attno

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

Re: [HACKERS] UNION ALL - Var attno

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

Re: [HACKERS] UNION ALL - Var attno

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,

Re: [HACKERS] UNION ALL - Var attno

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

Re: [HACKERS] UNION ALL - Var attno

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,

[HACKERS] UNION ALL - Var attno

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