Re: UNION ALL - Var attno

Поиск
Список
Период
Сортировка
От sri harsha
Тема Re: UNION ALL - Var attno
Дата
Msg-id CAP6OGLHr_EqLaP-PtfuJxBLPOPqVfXqW+TV_-MyB7kjmfGU1_w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: UNION ALL - Var attno  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: UNION ALL - Var attno  (Amit Langote <amitlangote09@gmail.com>)
Re: UNION ALL - Var attno  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Re: UNION ALL - Var attno  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

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 <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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: VS 2015 support in src/tools/msvc
Следующее
От: Andreas Seltenreich
Дата:
Сообщение: [sqlsmith] Failed assertion in BecomeLockGroupLeader