Thread: copyObject() ?
Hello all, AFAIC the relation between objects is not copied correctly by copyObject() (i.e the same pointers to an object are copied to different pointers by copyObject()). I think it makes copyObject() unreliable. I have some bug-reports due to this cause.(see attached file) We should patch one by one ? There is a way to maintain the list of (old,new) pairs during copyObject() operations. We could copyObject() correctly with this mechanism,though there may be the problem of performance. Comment ? Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> AFAIC the relation between objects is not copied correctly
> by copyObject() (i.e the same pointers to an object are copied
> to different pointers by copyObject()).
True, but it seems irrelevant to me --- as Jan Wieck was just pointing
out, no code should ever depend on pointer-equality in parse trees or
plan trees anyway.
> There is a way to maintain the list of (old,new) pairs during
> copyObject() operations.
I think we'd be better off fixing any places that mistakenly assume
pointer compare is sufficient. You didn't say which version you were
testing, but we know there are a few bugs like that in the current
CVS sources because of collateral damage from the EXCEPT/INTERSECT
patch. I believe the plan is to either fix them or back out the patch
before 6.5.
regards, tom lane
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > AFAIC the relation between objects is not copied correctly > > by copyObject() (i.e the same pointers to an object are copied > > to different pointers by copyObject()). > > True, but it seems irrelevant to me --- as Jan Wieck was just pointing > out, no code should ever depend on pointer-equality in parse trees or > plan trees anyway. > > > There is a way to maintain the list of (old,new) pairs during > > copyObject() operations. > > I think we'd be better off fixing any places that mistakenly assume > pointer compare is sufficient. You didn't say which version you were > testing, but we know there are a few bugs like that in the current > CVS sources because of collateral damage from the EXCEPT/INTERSECT > patch. I believe the plan is to either fix them or back out the patch > before 6.5. Yes, I removed a pointer comparison in the optimizer. It now uses equal(). Someone needs to go over EXCEPT/INTERSECT code and identify introduced problems or we are going to be chasing these introduced bugs for months. Anyone volunteering? -- 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, Pennsylvania19026
Hello all, > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Wednesday, February 24, 1999 12:16 AM > To: Hiroshi Inoue > Cc: pgsql-hackers > Subject: Re: [HACKERS] copyObject() ? > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > AFAIC the relation between objects is not copied correctly > > by copyObject() (i.e the same pointers to an object are copied > > to different pointers by copyObject()). > > True, but it seems irrelevant to me --- as Jan Wieck was just pointing > out, no code should ever depend on pointer-equality in parse trees or > plan trees anyway. > If multiple references are not necessary,why we don't allocate diffrent objects which have equal contents from the start ? It seems very difficult to prevent developpers from using the following fact implicitly. The same pointers always point the equal contents. ^^^^^^^^ Different pointers (as copyObject() currently generates) which have equal contents may have different contents some time. Isn't it a significant differnce ? > > There is a way to maintain the list of (old,new) pairs during > > copyObject() operations. > > I think we'd be better off fixing any places that mistakenly assume > pointer compare is sufficient. You didn't say which version you were > testing, My environment is v6.4.2. OK,I would test my cases again after the release of 6.5-BETA(v6.4.3?). TIA Hiroshi Inoue Inoue@tpf.co.jp