Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. oid2name: Add relation path to the information provided by -x/--extended

  1. oid2name : add objects file path

    David Bidoc <dcbidoc@gmail.com> — 2025-10-07T08:55:14Z

    Hello,

This is my first patch to the project.

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.

$ oid2name -p 5435 -x
All databases:
    Oid  Database Name  Tablespace    Filepath
----------------------------------------------
  16392             b1  pg_default  base/16392
      5       postgres  pg_default      base/5
      4      template0  pg_default      base/4
      1      template1  pg_default      base/1

$ oid2name -p 5435 -d b1 -x
>From database "b1":
  Filenode  Table Name    Oid  Schema  Tablespace          Filepath
-------------------------------------------------------------------
     16393          t1  16393  public  pg_default  base/16392/16393

$ oid2name -p 5435 -d b1 -i -x
>From database "b1":
  Filenode  Table Name    Oid  Schema  Tablespace          Filepath
-------------------------------------------------------------------
     16393          t1  16393  public  pg_default  base/16392/16393
     16396   t1_c1_idx  16396  public  pg_default  base/16392/16396

Regards

David Bidoc

  2. Re: oid2name : add objects file path

    Euler Taveira <euler@eulerto.com> — 2025-10-07T09:47:28Z

    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/

  3. Re: oid2name : add objects file path

    David Bidoc <dcbidoc@gmail.com> — 2025-10-08T12:44:14Z

    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

  4. Re: oid2name : add objects file path

    Guillaume Lelarge <guillaume.lelarge@dalibo.com> — 2025-11-26T20:02:45Z

    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

  5. Re: oid2name : add objects file path

    David Bidoc <dcbidoc@gmail.com> — 2025-12-02T10:36:39Z

    > 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
>
>

  6. Re: oid2name : add objects file path

    Michael Paquier <michael@paquier.xyz> — 2025-12-04T00:46:04Z

    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

  7. Re: oid2name : add objects file path

    David Bidoc <dcbidoc@gmail.com> — 2025-12-15T14:30:53Z

    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

  8. Re: oid2name : add objects file path

    Euler Taveira <euler@eulerto.com> — 2025-12-15T23:39:28Z

    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/