On 12/27/17 15:18, Antonio Belloni wrote:
> I checked the code of pg_tablespace_databases, defined in
> src/backend/utils/adt/misc.c, and see that it uses a much simpler
> approach : It just reads the tablespaces directories and return the name
> of the directories that represents databases OIDs.
>
> Although the function works as expected, I can see some issues not
> addressed in the code :
>
> - It does not check for permissions. Any user can execute it;
> - It does not check if the platform supports symlinks, which can cause
> an error because the function is trying to follow the links defined in
> base/pg_tblspc.
>
> I could use the same approach and write a function that goes down one
> more level in the directory structure and find the objects' OIDs inside
> each database directory, but I don't know if this is the better way to
> do that.
The information of what object is in what tablespace already exists in
the system catalogs, so I don't think we need new ways to discover that
information. What the todo item referred to, I think, was having a way
to discover that across database boundaries. But I think that problem
is unsolvable by design, because you can't look into other databases.
Looking into the file system to discover the OIDs of objects might work,
but then you can't do anything with those OIDs without having access to
the respective database to resolve them.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services