RE: CLASSOID patch - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: CLASSOID patch
Date
Msg-id NABBINCKAKFCDDKMMJHGAEFHEOAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: CLASSOID patch  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
> -----Original Message-----
> From: chrisb@nimrod.itg.telstra.com.au
>
> 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.
>

Though the entries other than t_data in HeapTupleData
aren't stored to disk,HeapTupleData is just an extension
of HeapTupleHeaderData which represents the stored
format of tuples. Isn't it strange to you that htup.h is
dependent on rel.h ?

>
> 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.
>

AFAIK,it doesn't.

> *) 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.
>

It may be unnecessary for heap_insert/delete/update/mark4update().
I'm not sure however.

Hiroshi Inoue
Inoue@tpf.co.jp

pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: physical backup of PostgreSQL
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Big 7.1 open items