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

On Mon, May 01, 2000 at 03:12:44PM -0400, Tom Lane wrote:
> "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> > 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.
> 
> Not good enough --- the logical names of the temp tables (ie, the names
> they are given in pg_class) can't collide either, or we'll get failures
> from the unique index on pg_class relname.  It could be that schemas
> will provide a better answer to that point though.

Well, that unique index will have to go away, one way or another, since
schema's require multiple persistent tables with the same undecorated
relname in the same db. Adding the schema to the pg_class table is
probably where this has to go, then making the index over both fields.
Then, temp tables can be implemented as a session specific temp schema.

> 
> I concur with your observation that the semantics we give temp tables
> are more than the standard requires --- but I also concur with Bruce
> that it's an exceedingly useful extension.  ISTM if an application has
> to worry about whether its temp table name will collide with something
> else, then much of the value of the feature is lost.  So masking
> permanent table names is the right thing, just as local vars in
> subroutines mask global vars of the same name.  Again, maybe we can
> define schemas in such a way that the same effect can be gotten...

Agreed. The masking does require more than just having a special schema
for temp tables, though. SO, some version of Bruce's macro hack is still
required.

> 
> I didn't see what you did here, but I doubt that it was the right thing.

Probably not: this is my first extensive digging into the backend code.
And the whole reason this is a 'lets try and implement somne of this,
and go back to the discussion' patch, instead of a proposed addition.

In defense of what I _did_: The temp table relname hacking is still
in place, and seems to work, and could be left in place. However, I
knew that relname would not stay unique, once schema are implemented,
but physrelname would (since the smgr needs it). 

> There are two things going on: rel name and rel OID must both be unique
> within a database, but there can be duplicates across databases within
> an installation.  So, most of the backend assumes that rel name or
> rel OID is alone sufficient to identify a relation, and there are just
> a couple of places that interface to installation-wide structures
> (eg, the buffer manager and sinval-queue manager) that know they must
> attach the current database's name or OID to make the identifier
> globally unique.  This is one reason why a backend can't reconnect to
> another database on the fly; we've got no way to find all those
> database-dependent cache entries...
> 

Right. But it seems to me that everywhere the code uses just a relname, it
assumes the currently connected DB, when eventually gets to the reference
by the code that interfaces to the installation-wide structures, no? Once
schema are in place, this can no longer work. One hack would be to have a
'current schema', like current db, but that won't work, one query will
need to refery to schema other than the default for table references
(otherwise, they're not very useful, are they?)

> It's going to be *extremely* painful if more than one name/OID is needed
> to refer to a relation in many places in the backend.  I think we want
> to avoid that if possible.
> 
> It seems to me that what we want is to have schemas control the mapping
> from rel name to rel OID, but to keep rel OID unique within a database.
> So schemas are more closely related to the "temp table hack" than you
> think.
> 

So, relname cannot be enough. Isn't OID already sufficent though? I
thought oids are unique across the entire installation, not just a
particular db. In any case, the solution may be to convert relname
(+default or user supplied schema) to rel oid, as early as possible,
then indexing (and caching) on that. If oids are db specific, the code
that needs system wide uniqueness needs to add the db name/OID, just
like it does for relname.

Actually, I know that schemas are _closely_ related to the temp table hack
(which was Bruce's own word for it, BTW, not mine;-), hence my hijacking
of his RelationGetRelationName and RelationGetPhysicalRelationName
macros. I was hoping to get temp tables back (mostly) for free once
schemas are in, but I think the extended semantics will require leaving
something like the existing code in place.

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