RE: [HACKERS] copyObject() ?

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] copyObject() ?
Date: 1999-02-25 01:57:50
Message-ID: 000a01be6062$3f713d80$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello all,

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Wednesday, February 24, 1999 12:16 AM
> To: Hiroshi Inoue
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] copyObject() ?
>
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gerald L. Gay 1999-02-25 05:02:58 libpq and SPI
Previous Message Tom Lane 1999-02-25 01:50:34 BTW, datetime is busted in REL6_4 branch