Re: CLASSOID patch - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: CLASSOID patch
Date
Msg-id 3956CFD0.8C8C46FD@nimrod.itg.telecom.com.au
Whole thread Raw
In response to RE: CLASSOID patch  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: CLASSOID patch  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue wrote:
> The points I've noticed are the following.
> 
> 1) It seems not preferable to add an entry *relation* which is of
>     Relation type in HeapTupleData. Relation OID seems to be
>     sufficient for your purpose.

Only that I was contemplating whether there should also be a "tablename"
attribute in addition to "classoid"/"tableoid", and I thought that
somehow it should be easier to get from Relation to its name, although
it's not immediately obvious to me if it is possible. If it is easily
done it seems desirable not to force people to join with pg_class.

> 2) The change in optimizer/path/tidpath.c seems to have
>     no meaning.

Yes that was definitely a mistake, and is commented out as you see.

Specific questions I have about the patch are...

*) Does this change not add additional storage to disk? I understand it
doesn't, but I don't understand the details.

*) in access/heap/heapam.c I wildly inserted a tuple->relation =
relation everywhere I could see. Perhaps someone with more insight can
tell me if some of these are excessive, or conversly if there are some
other access methods which will cause it not to work.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CLASSOID patch
Next
From: Chris Bitmead
Date:
Subject: Re: About the pid and opts files