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

Reply via email to