Обсуждение: Function to return whole relation path?
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
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
David Christensen <david@endpoint.com> writes:
> On Feb 7, 2010, at 11:04 AM, Tom Lane wrote:
>> pg_relation_filepath(regclass) returns text
>> which would expose the output of relpath(), ie, the $PGDATA-relative
>> path name of the relation.
> 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?
No, I'm not inclined to go there. The set of actually existing segments
seems too volatile; and anyone worried about this probably can add a
star to the end of the pathname ...
regards, tom lane
On Feb 7, 2010, at 1:30 PM, Tom Lane wrote: > David Christensen <david@endpoint.com> writes: >> On Feb 7, 2010, at 11:04 AM, Tom Lane wrote: >>> pg_relation_filepath(regclass) returns text >>> which would expose the output of relpath(), ie, the $PGDATA-relative >>> path name of the relation. > >> 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? > > No, I'm not inclined to go there. The set of actually existing > segments > seems too volatile; and anyone worried about this probably can add a > star to the end of the pathname ... True, although it'd need to be more refined than just *, as you'd need to be careful to only pick up those related to the actual relid: "172744", "172744.1", etc, and not those with a common prefix: "1727441", "1727441.1", etc. (common prefix). If that needs to be someone else's problem, makes sense here. Regards, David -- David Christensen End Point Corporation david@endpoint.com