On Sat, 19 Jun 2004, Andreas Pflug wrote:


> >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.


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to