Re: RE: [PATCHES] relation filename patch - Mailing list pgsql-hackers

On Sun, Apr 30, 2000 at 10:18:56PM -0400, Bruce Momjian wrote:
> > > 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.
> > 

I didn't go to great trouble to keep the existing hack to the syscache
code working for temp tables, because I thought that the primary purpose
of that hack was to make sure the physical relation name, i.e. the file
name, would not collide for multiple backends. Tacking the OID onto
the filename fixes that.  Getting the right table for the user specific
namespace sounds like ... schemas, so I figured I could fix that in the
schema implementation.

However, I see now that the hack to the syscache actually implements
temp table override of an existing persistent relation, as well. Hmm,
is this override SQL92, or an extension? It seems to me that TEMPORARY
tables are not completely defined in the draft I have.  For example,
there's syntax defined for ON COMMIT PRESERVE ROWS, but the only semantics
seem to be some restrictions on check constraint definitions, not how
the temp table rows are supposed to be preserved.

Hmm. Further perusal leads me to believe that this override is a
standards extension, as the clause about the tablename being unique in
the current namespace does not have an exception for temporary tables.
Nothing wrong with that, just making it clear. What's the use/case for
this feature? Does it come from some other DMBS?


> > Second, I trust the patch keeps the on-disk file names similar to the
> > table names.  Doing some all-numeric file names just to work around NT
> > broken-ness is not going to fly.

The patch uses Tom Lane's makeObjectName code, to tack the oid on
the end of the relname, but keep it under NAMEDATALEN by trimming the
relname part.

> 
> I should add I have not seen this patch personally.  If it was sent to a
> mailing list, I somehow missed it.

It went to the patches list, although I'm still not getting mail from
there.  BTW, it's clearly marked 'experimental, not to include in CVS'
I'm not suggesting that this is the way to go: just testing how much
the assumption relname == filename has crept up through the code. Not
too bad, actually.

The bigger problem, for schema implementation, is that the assumption
'relname+dbname' is sufficent to uniquely identify a relation is more
pervasive: it's the basis of the relcache hash, isn't it? That's why I
changed the key for that hash. I'm not sure I got all the places that
make that assumption: in fact, the extra errors I get from the temptable
regresion tests strongly imply that I  missed a few (attempt to delete
non existent relcache entry.) In addition, doing it the way I did does
require that all storage managers assure uniqueness of the relphysname
across the entire DB. The current patch does that: the oid is unique.

Another way to go is to revert that change, but adding the schema to
the relcache key.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005