Gavin Sherry wrote:
>On Fri, 18 Jun 2004, Bruce Momjian wrote:
>
>[snip]
>
>
>
>>>TODO. You sound like a man who's expecting a
>>>several-generations-polished facility when we only just committed
>>>the first version today. I do not feel a need to have any of these
>>>features in 7.5 ...
>>>
>>>
>>I just need to know what to add to the TODO list, and so we can answer
>>people who are going to ask for this functionality. Added to TODO:
>>
>> * 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|...} ?
>
I checked this to implement it, and found it being less then trivial
when *all* objects of a tablespace should be displayed, not just the
ones in the current database.
There seem to be several ways to implement:
(1) dblink like access iterating all databases. This seems
extraordinarily expensive
(2) low level scanning tablespace location, then try to translate found
oids to names withoug SPI. Probably not desirable.
(3) extending parser/executor to allow a table specification of the form
database.namespace.tablename. This has been requested several times
before, but was rejected, with the advise to use dblink.
(4) Copy the contents of the desired cross-db table to a temporary table
(generate new oid in local db, copy cross-db table file to new oid file,
insert pg_class). A typically weird Andreas' approach :-)
Regards,
Andreas
