From: | David Christensen <david(at)endpoint(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Function to return whole relation path? |
Date: | 2010-02-07 18:47:48 |
Message-ID: | 2433EEEC-8CD2-4D95-9D70-F1F6DB6C5B86@endpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)endpoint(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-02-07 19:13:04 | Re: damage control mode |
Previous Message | Andres Freund | 2010-02-07 18:27:02 | Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |