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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
