Gavin Sherry <[EMAIL PROTECTED]> writes: > On Fri, 18 Jun 2004, Bruce Momjian wrote: >> * Allow reporting of which objects are in which tablespaces
> Do we need an information_schema.tablespaces view as well as an update to > information_schema.{tables|indexes|...} ? That would depend on your theology about whether implementation-specific additions to information_schema are a good idea or not. I'd lean against doing this myself. ISTM the entire point of information_schema is to be standard, and additions are, well, not. Worse, they might conflict with future extensions to the standard. I don't actually see a way *inside the database* to implement Bruce's TODO item; there's no way for a backend to look at the catalogs of other databases. We could look to see which databases had nonempty subdirectories of a tablespace, and report those databases by name, but explaining exactly what's inside those subdirectories is a lot harder. It might be better to think about supporting this need with oid2name or some similar client-level tool. It's easy to see how oid2name might be extended to produce an output like Tablespace t1 Database d1 Table x Table y Database d2 etc etc regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings