RE: RE: [PATCHES] relation filename patch

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
>
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > -----Original Message-----
> > > From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> > >
> > > > If I recognize correctly,RelationGetRelationName() macro returns the
> > > > relation name local to the backend and RelationGetPhysicalRelation-
> > > > Name() macro returns pg_class entry name currently. Those names
> > > > are same unless the relation is a temporary relation. They may be
> > > > able to have separate entries in pg_class. I don't know why they
> > > > don't currently.
> > >
> > > Different backends can have the same temp file names at the same time,
> > > so you would have to have a pg_class tuple that is visible only to the
> > > current transactions, and allow multiple duplicate ones.
> Easier not to
> > > have it in pg_class and just hack the syscache code.
> > >
> >
> > You are right. It seems sufficient to have an entry in relation
> descriptor
> > for the local relation name.
>
> Actually it is the system catalog cache. The pg_class lookups to a
> translation from temp to physical name on pg_class lookups. Only a few
> lines in backend/utils/cache/syscache.c:
>
> /* temp table name remapping */
> if (cacheId == RELNAME)
> {
> char *nontemp_relname;
>
> if ((nontemp_relname =
> get_temp_rel_by_username(DatumGetPointer(key1))) != NULL)
> key1 = PointerGetDatum(nontemp_relname);
> }
>
> That is it, and temprel.c.
>

It's diffrent from what I meant.
My question is why the macro RelationGetRelationName()
needs the following implementation.
Is it bad to add another entry such as rd_username to relation
descriptor ?

#define RelationGetRelationName(relation) \
(\
(strncmp(RelationGetPhysicalRelationName(relation), \
"pg_temp.", strlen("pg_temp.")) != 0) \
? \
RelationGetPhysicalRelationName(relation) \
: \
get_temp_rel_by_physicalname( \
RelationGetPhysicalRelationName(relation)) \
)

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp