In connection with the relation-mapping patch I proposed a functionpg_relation_filenode(regclass) returns oid
which client code would need to use instead of looking at
pg_class.relfilenode, if it wants to get a number that will be
meaningful for mapped system catalogs. I still think we need that,
but while thinking about how it'd be used, I wondered if it wouldn't
be far more useful to providepg_relation_filepath(regclass) returns text
which would expose the output of relpath(), ie, the $PGDATA-relative
path name of the relation. So you'd get something like
"base/58381/92034" or "pg_tblspc/48372/8.5_201002061/68483/172744".
For clients that are actually trying to match up files with tables,
this would avoid having to essentially duplicate the knowledge
embedded in relpath(). In particular, the recent decision to
include catversion in tablespace subdirectories is going to be a
significant PITA for such clients, as there is no easy way to
discover catversion by asking the backend.
I don't see any security issue here, since this wouldn't give you
any information that's not readily available (like absolute pathnames
on the server) --- but it would avoid code duplication.
Objections, better ideas?
BTW, I think both functions should return NULL for relations without
storage.
regards, tom lane