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/
End Point Corporation
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-02-07 19:13:04|
|Subject: Re: damage control mode|
|Previous:||From: Andres Freund||Date: 2010-02-07 18:27:02|
|Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)|