Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
Date
Msg-id 18849.943928436@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Any ideas on this one?

>> Uncle George <gatgul@voicenet.com> writes:
>>>> In the regression test rules.sql there is this SQL command
>>>> update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
>>>> Which causes my alpha port to go core.
>>
>> Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
>> patiently waiting for Jan to decide what to do about it :-(
>>
>> You could stop the coredump by putting a test into ResolveNew:
>>
>>           {
>>               *nodePtr = copyObject(n);
>> +             if (IsA(*nodePtr, Var))
>>                   ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
>>           }
>>
>> but what's not so clear is what's supposed to happen when the
>> replacement item *isn't* a Var.  I tried to convince myself that nothing
>> needed to happen in that case, but wasn't successful.  (Presumably the
>> replacement expression contains no instances of the variable being
>> replaced, so recursing into it with ResolveNew shouldn't be needed
>> --- but maybe its varlevelsup values need adjusted?)


That code currently reads like:

                /* Make a copy of the tlist item to return */
                n = copyObject(n);
                if (IsA(n, Var))
                {
                    ((Var *) n)->varlevelsup = this_varlevelsup;
                }
                /* XXX what to do if tlist item is NOT a var?
                 * Should we be using something like apply_RIR_adjust_sublevel?
                 */
                return n;

so it won't coredump when the tlist item is not a Var, but I'm not
convinced it does the right thing either.  Jan is the only man who
understands that code well enough to say what needs to be done about
it...

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] having bug report
Next
From: Bruce Momjian
Date:
Subject: Re: A bug in NOT IN (SELECT ...