Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
От | Bruce Momjian |
---|---|
Тема | Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha |
Дата | |
Msg-id | 199911292246.RAA16125@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] RedHat6.0 & Alpha (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
|
Список | pgsql-hackers |
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?) > > regards, tom lane > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: