On Feb 7, 2010, at 11:04 AM, Tom Lane wrote:
In connection with the relation-mapping patch I proposed a function
pg_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 provide
pg_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?
Should this return multiple values (text[] or SETOF text) for tables
which wrapped over the single file-limits (1GB, IIRC)? So: "pg_tblspc/
48372/8.5_201002061/68483/172744", "pg_tblspc/
48372/8.5_201002061/68483/172744.1", etc?
Regards,
David
--
David Christensen
End Point Corporation
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
