Function to return whole relation path?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Function to return whole relation path?
Date: 2010-02-07 17:04:57
Message-ID: 24638.1265562297@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

BTW, I think both functions should return NULL for relations without
storage.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-07 17:15:49 Re: pg_class has no toast table?
Previous Message Simon Riggs 2010-02-07 16:58:44 Re: pg_class has no toast table?