Обсуждение: 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