"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> 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.
Right, there would probably be a unique index on schema name + relname.
> 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?)
I was sort of envisioning a search path of schema names. Temp table
masking could be implemented by pushing the session-local schema onto
the front of the search path. Not sure how that relates to SQL3's ideas
about schemas, however.
> 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.
Er, well, no. Consider pg_class, which has both the same name and the
same OID in every DB in the installation --- but we have to treat it
as separately instantiated in each DB. Most of the system tables work
that way. OTOH we have a couple of top-level tables like pg_shadow,
which are the same table for all DBs in the installation.
It could be that we ought to eliminate the whole notion of separate
databases within an installation, or more accurately merge it with the
concept of schemas. Really, the existing database mechanism is sort
of a limited implementation of schemas.
> 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.
Right, but there wouldn't be only one default schema, there'd be some
kind of search path in which an unqualified relname would be sought.
regards, tom lane
