Re: UNION ALL - Var attno - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: UNION ALL - Var attno
Date
Msg-id CAFjFpRd3L2foEXJeahPuJzfkz24CUfV5Vw-37g84K2ptBr4e_w@mail.gmail.com
Whole thread Raw
In response to Re: UNION ALL - Var attno  (sri harsha <sriharsha9992@gmail.com>)
List pgsql-hackers


On Fri, Apr 29, 2016 at 11:12 AM, sri harsha <sriharsha9992@gmail.com> 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 *(Node *) node in a debugger, it will tell you the type of node. What does that print?
 
On Fri, Apr 29, 2016 at 10:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
sri harsha <sriharsha9992@gmail.com> 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 assuming it's a Var?  The fact that 141 is the pg_proc OID of int4mul
lends considerable weight to this suspicion ...

                        regards, tom lane




--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: 9.6 and fsync=off
Next
From: Amit Kapila
Date:
Subject: Re: [sqlsmith] Crash in apply_projection_to_path