Обсуждение: Add OID descriptions to dumped parse/query/plan trees

Hi Hackers,

When reading dumped parse/query/plan trees, sometime we want to know what exact type/operator/function an OID stands for. I just added a new feature that will add some OID descriptions to the dump trees, like:

```

      :scan.scanrelid 1
      :indexid 16474 # index orders_pkey
      :indexqual (
         {OPEXPR
         :opno 521 # operator >(integer,integer)
         :opfuncid 147 # function int4gt(integer,integer)
         :opresulttype 16 # type boolean
         :opretset false
         :opcollid 0

```

The patch file is attached.

Best regards,

--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Fri, 22 Aug 2025 at 14:08, Chao Li <li.evan.chao@gmail.com> wrote:
>
> Hi Hackers,
>
> When reading dumped parse/query/plan trees, sometime we want to know what exact type/operator/function an OID stands
for.I just added a new feature that will add some OID descriptions to the dump trees, like:
 
>
> ```
>
>       :scan.scanrelid 1
>       :indexid 16474 # index orders_pkey
>       :indexqual (
>          {OPEXPR
>          :opno 521 # operator >(integer,integer)
>          :opfuncid 147 # function int4gt(integer,integer)
>          :opresulttype 16 # type boolean
>          :opretset false
>          :opcollid 0
>
> ```
>
> The patch file is attached.
>
> Best regards,
>
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/

Hi!

In commit message:

"This patch also fixes a trivial bug where an extra whitespace was added
when dumping an array, for example:..."

Maybe worth making this a separate change?

I can see that plain text comments can be beneficial for debug
purposes. However, I am not terribly sure these comments should be
included in the text dump unconditionally. This can break some
third-party query analysing tools (as it changes format). Can we make
this optional?

-- 
Best regards,
Kirill Reshke

Chao Li <li.evan.chao@gmail.com> writes:
> When reading dumped parse/query/plan trees, sometime we want to know 
> what exact type/operator/function an OID stands for. I just added a new 
> feature that will add some OID descriptions to the dump trees, like:

This is really quite a bad idea.  It means that the dump code has to
execute in a live (not-aborted) transaction, which is not a
requirement it had before, and will complicate some debugging
scenarios.  The extra catalog accesses that could occur might also
cause problems, maybe even deadlocks in some uses.  I'd prefer to
keep the flexibility to be able to call pprint from pretty much
anywhere.

Also, AFAICS this breaks re-reading of dump trees, which breaks all
kinds of stuff (rules, views, parallel query, etc).

            regards, tom lane