Обсуждение: AW: Big 7.1 open items

> That'd work fine for me, but I think Bruce was arguing for paths that
> included the database name.  We'd end up with paths that go something
> like
>     ..../data/tablespaces/TABLESPACEOID/RELATIONOID
> (plus some kind of decoration for segment and version), so you'd have
> a hard time telling which files in a tablespace belong to which
> database.

Well ,as long as we have the file per object layout it probably makes sense
to 
have "speaking paths", But I see no real problem with:

..../data/tablespacename/dbname/RELATIONOID[.dat|.idx]

RELATIONOID standing for whatever the consensus will be.
I do not really see an argument for using a tablespaceoid instead of
it's [maybe mangled] name.

Andreas

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> I do not really see an argument for using a tablespaceoid instead of
> it's [maybe mangled] name.

Eliminating filesystem-based restrictions on names, for one.
For example we'd not have to forbid slashes and (probably) backquotes
in tablespace names if we did this, and we'd not have to worry about
filesystem-induced limits on name lengths.  Renaming a tablespace
would also be trivial instead of nigh impossible.

It might be that using tablespace names as directory names is worth
enough from the admin point of view to make the above restrictions 
acceptable.  But it's a tradeoff, and not one with an obvious choice
IMHO.
        regards, tom lane