Tom Lane writes:
> I don't think it's a good idea to have to consult pg_tablespace to find
> out where a table actually is --- I think the pathname (or smgr access
> token as Ross would call it ;-)) ought to be determinable from just the
> pg_class entry.
That's why I suggested the table space oid. That would be readily
available from pg_class.
> Tablespaces can have logical names stored in pg_tablespace; they just
> can't contribute more than a dozen or so characters to file pathnames
> under the implementation I'm proposing. That doesn't seem too
> unreasonable; the pathname part can be some sort of abbreviated name.
Since the abbreviated name is really only used internally it might as well
be the oid. Otherwise you create a weird functional dependency like the
pg_shadow.usesysid field that's just an extra layer of maintenance.
> this implementation mechanism will support either policy choice ---
> original relname in the filename, or just a numeric ID for the
> filename
But when you look at a file name `12345_accounts_recei' you know neither
* whether the table name was really `accounts_recei' or whether the name
was truncated
* whether the table still has that name, whatever it was
* what table this is at all
So in the aggregate you really know less than nothing. :-)
> > Why not use OID.[SEGMENT.]VERSION for the physical relname (different
> > order possible)?
>
> Doesn't give you a manageable way to split segments across different
> disks.
Okay, so maybe ${base}/TABLESPACEOID/SEGMENT/RELOID.VERSION.
This doesn't need any catalog lookup outside of pg_class, yet it's still
easy to resolve to human-readable names by simple admin tools (SELECT *
FROM pg_foo WHERE oid = xxx). VERSION would be unique within a conceptual
relation, so you could even see how many times the relation was altered in
major ways (kind of).
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
