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
david@endpoint.com