On Thu, 10 Jun 1999, Tom Lane wrote:
>"Pedro J. Lobo" <pjlobo@euitt.upm.es> writes:
>> #0 replace_opid (oper=0x4015aad0) at nodeFuncs.c:95
>> #1 0x1201208b0 in fix_opid (clause=0x14015aaa0) at clauses.c:554
>
>> (gdb) p *((Expr *) clause)
>> $3 = {type = T_Expr, typeOid = 23, opType = OP_EXPR, oper = 0x4015aad0,
>> args = 0x14015ab30}
>
>> I don't know if ((Expr*) clause)->oper should point to itself as it seems
>> to do,
>
>It shouldn't ever point to itself, but it looks to me like it's not ---
>the low order bits of clause are ...aaa0 and oper is ...aad0.
Ooops, you are right! Now I am using a bigger font :-)
>> but certainly its value is passed though an int variable and is
>> truncated.
>
>Looks that way doesn't it :-(. I did some quick scratching around in
>the sources and couldn't find any obvious mistakes of that ilk. Most of
>the code that touches Oper nodes would have been exercised heavily long
>before we get to the rules regression test, so I'm not sure what to think.
I have also looked at the warnings that arise in the compilation process,
and haven't found any that could be related to that.
>> If someone points me to the right place to look, I can play a bit more
>> with gdb and try to find the cause.
>
>The Expr node was presumably made by make_op() in
>backend/parser/parse_oper.c, although the tree might have been copied at
>least once using the functions in backend/nodes/copyfuncs.c. Good luck!
Ok, I'll let you know if/when I find something (or, more probably, when I
have more questions ;-)
Regards,
Pedro.
--
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 91 336 78 19
Centro de Cálculo Fax: +34 91 331 92 29
E.U.I.T. Telecomunicación e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7 E-28031 Madrid - España / Spain