Обсуждение: 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
>
>