Обсуждение: oid2name : add objects file path

On Tue, Oct 7, 2025, at 5:55 AM, David Bidoc wrote:
> This is my first patch to the project.
>

Welcome to Postgres community.

> I noticed that the oid2name tool does not display the file path of objects.
>
> I thought this could be interesting and that others might find it 
> useful, so I made a little patch to display the full path of objects 
> retrieved by the oid2name tool. These will be displayed using the -x 
> --extended option.
>

I didn't review your patch in details but I noticed 2 things that should be
improved:

1. The database query is wrong because it is considering that all databases are
in the default tablespace. If you create a database in a different tablespace
you will notice the mistake.

2. I suggest that you change one of the examples (maybe the last one) to
illustrate this feature.

Since you are in this area, you could create a separate patch for show the
tablespace location (-s option). Use pg_tablespace_location function.

Register your patch for the next commitfest so we don't lose track of it. [1]
If you don't have an account, the 'Log In' link will redirect you to the page
to create a new one or even allow you to use a third party sign in.

[1] https://commitfest.postgresql.org/56/


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/

On Tue, Oct 7, 2025 at 11:47 AM Euler Taveira <euler@eulerto.com> wrote:

> 1. The database query is wrong because it is considering that all databases are
> in the default tablespace. If you create a database in a different tablespace
> you will notice the mistake.

Thank you for your feedback.

Indeed, the path is wrong if the default tablespace is not used.
I did not find a simple way to retrieve the database path (to my
knowledge there is
no function like pg_database_location() or something similar), so I have removed
this part from the patch for now.

>
> 2. I suggest that you change one of the examples (maybe the last one) to
> illustrate this feature.

Here is a new example by adding a table in a different tablespace :

$ oid2name -p 5435 -d b1 -t t2 -x
From database "b1":
  Filenode  Table Name    Oid  Schema  Tablespace
               Filepath
----------------------------------------------------------------------------------------------
     16403          t2  16403  public     tblspc1
pg_tblspc/16393/PG_19_202510082/16384/16403


> Since you are in this area, you could create a separate patch for show the
> tablespace location (-s option). Use pg_tablespace_location function.
>
I attached a new patch to add a column Tablespace Location to the -s option.

$ oid2name -p 5435 -s
All tablespaces:
    Oid  Tablespace Name  Tablespace Location
---------------------------------------------
   1663       pg_default
   1664        pg_global
  16393          tblspc1      /mnt/tblspc1/pg

> Register your patch for the next commitfest so we don't lose track of it. [1]
> If you don't have an account, the 'Log In' link will redirect you to the page
> to create a new one or even allow you to use a third party sign in.
>
> [1] https://commitfest.postgresql.org/56/
>

Done.
https://commitfest.postgresql.org/patch/6111/

Regards
David Bidoc

Hi David,

I just looked at the commit fest entry and the bot says your patch needs
a rebase. Can you do it? Thanks.

Regards.

On 08/10/2025 14:44, David Bidoc wrote:
> On Tue, Oct 7, 2025 at 11:47 AM Euler Taveira <euler@eulerto.com> wrote:
>
>> 1. The database query is wrong because it is considering that all databases are
>> in the default tablespace. If you create a database in a different tablespace
>> you will notice the mistake.
>
> Thank you for your feedback.
>
> Indeed, the path is wrong if the default tablespace is not used.
> I did not find a simple way to retrieve the database path (to my
> knowledge there is
> no function like pg_database_location() or something similar), so I have removed
> this part from the patch for now.
>
>>
>> 2. I suggest that you change one of the examples (maybe the last one) to
>> illustrate this feature.
>
> Here is a new example by adding a table in a different tablespace :
>
> $ oid2name -p 5435 -d b1 -t t2 -x
>  From database "b1":
>    Filenode  Table Name    Oid  Schema  Tablespace
>                 Filepath
> ----------------------------------------------------------------------------------------------
>       16403          t2  16403  public     tblspc1
> pg_tblspc/16393/PG_19_202510082/16384/16403
>
>
>> Since you are in this area, you could create a separate patch for show the
>> tablespace location (-s option). Use pg_tablespace_location function.
>>
> I attached a new patch to add a column Tablespace Location to the -s option.
>
> $ oid2name -p 5435 -s
> All tablespaces:
>      Oid  Tablespace Name  Tablespace Location
> ---------------------------------------------
>     1663       pg_default
>     1664        pg_global
>    16393          tblspc1      /mnt/tblspc1/pg
>
>> Register your patch for the next commitfest so we don't lose track of it. [1]
>> If you don't have an account, the 'Log In' link will redirect you to the page
>> to create a new one or even allow you to use a third party sign in.
>>
>> [1] https://commitfest.postgresql.org/56/
>>
>
> Done.
> https://commitfest.postgresql.org/patch/6111/
>
> Regards
> David Bidoc


--
Guillaume Lelarge
Consultant
https://dalibo.com

> Hi David,

Hi Guillaume,

> I just looked at the commit fest entry and the bot says your patch needs
> a rebase. Can you do it? Thanks.

I attached the rebased patch.
Any feedback would be appreciated.

Regards.

On Wed, Nov 26, 2025 at 9:02 PM Guillaume Lelarge
<guillaume.lelarge@dalibo.com> wrote:
>
> Hi David,
>
> I just looked at the commit fest entry and the bot says your patch needs
> a rebase. Can you do it? Thanks.
>
> Regards.
>
> On 08/10/2025 14:44, David Bidoc wrote:
> > On Tue, Oct 7, 2025 at 11:47 AM Euler Taveira <euler@eulerto.com> wrote:
> >
> >> 1. The database query is wrong because it is considering that all databases are
> >> in the default tablespace. If you create a database in a different tablespace
> >> you will notice the mistake.
> >
> > Thank you for your feedback.
> >
> > Indeed, the path is wrong if the default tablespace is not used.
> > I did not find a simple way to retrieve the database path (to my
> > knowledge there is
> > no function like pg_database_location() or something similar), so I have removed
> > this part from the patch for now.
> >
> >>
> >> 2. I suggest that you change one of the examples (maybe the last one) to
> >> illustrate this feature.
> >
> > Here is a new example by adding a table in a different tablespace :
> >
> > $ oid2name -p 5435 -d b1 -t t2 -x
> >  From database "b1":
> >    Filenode  Table Name    Oid  Schema  Tablespace
> >                 Filepath
> > ----------------------------------------------------------------------------------------------
> >       16403          t2  16403  public     tblspc1
> > pg_tblspc/16393/PG_19_202510082/16384/16403
> >
> >
> >> Since you are in this area, you could create a separate patch for show the
> >> tablespace location (-s option). Use pg_tablespace_location function.
> >>
> > I attached a new patch to add a column Tablespace Location to the -s option.
> >
> > $ oid2name -p 5435 -s
> > All tablespaces:
> >      Oid  Tablespace Name  Tablespace Location
> > ---------------------------------------------
> >     1663       pg_default
> >     1664        pg_global
> >    16393          tblspc1      /mnt/tblspc1/pg
> >
> >> Register your patch for the next commitfest so we don't lose track of it. [1]
> >> If you don't have an account, the 'Log In' link will redirect you to the page
> >> to create a new one or even allow you to use a third party sign in.
> >>
> >> [1] https://commitfest.postgresql.org/56/
> >>
> >
> > Done.
> > https://commitfest.postgresql.org/patch/6111/
> >
> > Regards
> > David Bidoc
>
>
> --
> Guillaume Lelarge
> Consultant
> https://dalibo.com
>
>

On Tue, Dec 02, 2025 at 11:36:39AM +0100, David Bidoc wrote:
> I attached the rebased patch.
> Any feedback would be appreciated.

Your patch still fails to apply on HEAD for all the changes of
contrib/oid2name/oid2name.c.  Please see the following:
https://commitfest.postgresql.org/patch/6111/

It also seems like Euler's feedback has not been answered.  I am
pretty sure that he was referring about the addition of an example in
the documentation, or at least refreshing the areas of the docs that
are impacted with your change (no clear idea about all that without a
rebased patch).
--
Michael

Hi Michael

On Thu, Dec 4, 2025 at 1:46 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Dec 02, 2025 at 11:36:39AM +0100, David Bidoc wrote:
> > I attached the rebased patch.
> > Any feedback would be appreciated.
>
> Your patch still fails to apply on HEAD for all the changes of
> contrib/oid2name/oid2name.c.  Please see the following:
> https://commitfest.postgresql.org/patch/6111/
>

Thank you for your feedback.
I attached the rebased and updated patch.

> It also seems like Euler's feedback has not been answered.  I am
> pretty sure that he was referring about the addition of an example in
> the documentation, or at least refreshing the areas of the docs that
> are impacted with your change (no clear idea about all that without a
> rebased patch).

I updated the documentation example about the -x option :

$ # you can mix the options, and get more details with -x
$ oid2name -d alvherre -t accounts -f 1155291 -x
From database "alvherre":
  Filenode     Table Name      Oid  Schema  Tablespace            Filepath
--------------------------------------------------------------------------
    155173       accounts   155173  public  pg_default   base/17228/155173
   1155291  accounts_pkey  1155291  public  pg_default  base/17228/1155291

I modified the example already used to maintain consistency.

--
David Bidoc

On Mon, Dec 15, 2025, at 11:30 AM, David Bidoc wrote:
>
> Thank you for your feedback.
> I attached the rebased and updated patch.
>

This patch was in the previous CF, I'm wondering that's why the "Emails" are
not reflecting the latest patches and the CF bot was not trying it. I moved
this patch to the next CF (PG19-4).  Hopefully, the CF entry will catch up in a
couple of hours.

https://commitfest.postgresql.org/patch/6111/


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/

On Mon, 2025-12-15 at 15:30 +0100, David Bidoc wrote:
> I attached the rebased and updated patch.

That patch looks good to me, and I think that is a useful addition.

If you want to display the path of databases as well, as you tried to
do in the original patch, I think the way to go would be to write a
new SQL function pg_database_filepath() similar to pg_relation_filepath().
That shouldn't be too hard - would you want to try that?

Other than that, you could try to propose a commit message and
prepare your patch with

  git format-patch -v5 -1 -o /mypatches HEAD

after committing it to your branch.  That would make the committer's
work easier.

Yours,
Laurenz Albe

On Wed, Jan 14, 2026 at 06:24:56AM +0100, Laurenz Albe wrote:
> On Mon, 2025-12-15 at 15:30 +0100, David Bidoc wrote:
> > I attached the rebased and updated patch.
> 
> That patch looks good to me, and I think that is a useful addition.
> 
> If you want to display the path of databases as well, as you tried to
> do in the original patch, I think the way to go would be to write a
> new SQL function pg_database_filepath() similar to pg_relation_filepath().
> That shouldn't be too hard - would you want to try that?
> 
> Other than that, you could try to propose a commit message and
> prepare your patch with
> 
>   git format-patch -v5 -1 -o /mypatches HEAD
> 
> after committing it to your branch.  That would make the committer's
> work easier.

I took a look with Phil Alger and we just have a couple of cosmetic
suggestions.

* There is an extra period (.) added to the change in the documentation.
* We would suggest using "Path" instead of "Filepath" in the column
  name.  While "Filepath" more closely reflects the the function used,
  "Path" reads a little more smoothly, and text in existing
  documentation tends to only reads "path" instead of "file path" when
  referring to paths on the filesystem.

Regards,
Mark
--
Mark Wong <markwkm@gmail.com>
EDB https://enterprisedb.com

On Wed, Feb 04, 2026 at 12:22:40PM -0800, Mark Wong wrote:
> I took a look with Phil Alger and we just have a couple of cosmetic
> suggestions.
>
> * There is an extra period (.) added to the change in the documentation.
> * We would suggest using "Path" instead of "Filepath" in the column
>   name.  While "Filepath" more closely reflects the the function used,
>   "Path" reads a little more smoothly, and text in existing
>   documentation tends to only reads "path" instead of "file path" when
>   referring to paths on the filesystem.

Yes, let's just use Path for the whole concept.  The two code paths
changed apply to -x, with -t able to filter the data for a single
table.  The docs have only one example when combining -x and -t,
meaning that the changes in the patch are OK.

Applied with these changes.  Sorry for the delay (I had this patch
marked on my stack of TODO things).
--
Michael