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

From Uncle George
Subject Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
Date
Msg-id 38431247.CE0D5122@voicenet.com
Whole thread Raw
In response to Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
I'm sorry, the resultant node as returned is not expected. The solution, as
provided,  did stop the insidious erasure of a field in a structure it did not own.
I'm content ( but i dont know any better )
If ur asking me what one is suppose to do at this point  - I dunno.
gat

Bruce Momjian wrote:

> 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 by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Re: pg_ctl