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 19:46:20 |
Message-ID: | 7845E359-D0ED-4B2B-9195-727D997BEB5D@endpoint.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb 7, 2010, at 1:30 PM, Tom Lane wrote:
> David Christensen <david(at)endpoint(dot)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(at)endpoint(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-02-07 19:50:05 | Re: Confusion over Python drivers |
Previous Message | Tom Lane | 2010-02-07 19:30:48 | Re: Function to return whole relation path? |