Re: Function to return whole relation path?

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

In response to

Browse pgsql-hackers by date

  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?