"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.
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...
> 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 didn't see what you did here, but I doubt that it was the right thing.
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...
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.
regards, tom lane
