On Sat, 19 Jun 2004, Andreas Pflug wrote:
[snip]
> >I don't think we should try and show all objects for a tablespace in
> >information_schema.
> >
> Agreed, information_schema is database specific. I was thinking about a
> pg_tablespace_contents(..) function anyway.
>
> >Being able to list all objects in a tablespace, including which databases
> >they are in, is clearly useful, however (eg: hunting down use of a give
> >tablespace that you want dropped). Sounds like a script in contrib (or the
> >main source tree?) to me.
> >
> >
> You're suggesting the dblink way using a shell script. Imagine 20, 200,
> ... databases. This would be a costly thing (and has to be implemented
> differently in win32).
> I'd like to see an implementation that enables gui interfaces to show
> objects that depend on a tablespace, so you'd need to be aware of a user
> clicking on "show what's in that tablespace" and he probably wouldn't
> expect to wait an extended period of time for all databases to be
> scanned, or impose a 200-connection load on the server.
I see this more as a script like Tom described in another email. We'd have
a list of tablespacecs and databases and scan each database (on connection
at a time) and get the information the user wants.
> IMHO checking objects in a tablespace is a routine administrative task,
> so it should be supported natively by the server without need of
> contribs. And for win user acceptance, a command line tool won't be
> sufficient either.
I would debate that.
Firstly, tablespaces aren't supported on windows yet. Secondly, I'd think
that Unix users would be fine with a command line tool, especially one
that can connect to a remote host.
For those not used to command line tools, I can imagine extensions to
pgadmin or phppgadmin.
Gavin
