Re: Raw parse tree is not dumped to log

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Raw parse tree is not dumped to log
Date: 2025-08-04 07:53:24
Message-ID: CAEoWx2knkBNrRMA0noWa3_1UU338uzKi3uYBnMCt6q9uoo6ZqQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was reviewing some patches today, and during debugging the patches, I
wanted to view raw parse tree, so I had to apply my local patch of dumping
raw parse for every review, which was so inconvenient.

You may argue that raw parse tree might not be useful for every reviews. I
am still ramping up PG development, I'd like to tune SQL statements and see
differences of resulting parse trees.

So, I made this patch. The change is quiet simple. I just searched for
"Debug_print_parse", and added a new option "Debug_print_raw_parse". Only
when the new option is turned on, raw parse tree will be dumped to logs.
This way will not make noise to people who are not interested in raw parse
tree.

I have run the following tests:

1. In an existing database, edit postgres.conf and add
"debug_print_raw_parse = on", then raw parse tree is dumped to logs as
expected.
2. Init a new database, "debug_print_raw_parse = off" appears in
postgres.conf as expected.
3. "make check" passed

This patches touches config.sgml and rules.sgml, I don't know how to test
the doc changes, any suggestion?

One thing I want reviewer's opinion is that, if start "postgres -d 3", it
originally only turn on debug_print_parse, now it will turn on
debug_print_raw_parse as well, which potentially make people who don't want
raw parse tree unhappy. Maybe use "-d 5" or not turning on
debug_print_raw_parse at all by "-d"? WDYT?

Chao Li (Evan)
------------------------------
HighGo Software Inc.
https://www.highgo.com/

Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> 于2025年8月1日周五 16:10写道:

> Hi Tatsuo, thanks for pointing out the past conversation.
>
> So, the requirement got 1 more vote from me. But to not make noise to
> people who are not interested in raw parse tree, I guess it's better to add
> a new option "debug_print_raw_parse". For people who are interested in raw
> parse tree, turning on a flag once is much more convenient than typing a
> command in the debugger for every trace.
>
> I will wait to see if Tom still objects to adding that. I will not make
> the code change unless I see a hint of "go".
>
> Chao Li (Evan)
> ------------------------------
> HighGo Software Inc.
> https://www.highgo.com/
>
>
> Tatsuo Ishii <ishii(at)postgresql(dot)org> 于2025年8月1日周五 15:18写道:
>
>> > Before submitting this trivial patch, I still want to confirm with the
>> > community if it's intentional to not dump raw parse tree?
>>
>> For your reference, here's the past discussion:
>>
>> https://www.postgresql.org/message-id/flat/20080730.172949.132921436.t-ishii%40sraoss.co.jp
>>
>> Best regards,
>> --
>> Tatsuo Ishii
>> SRA OSS K.K.
>> English: http://www.sraoss.co.jp/index_en/
>> Japanese:http://www.sraoss.co.jp
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-08-04 07:56:43 Re: Improve LWLock tranche name visibility across backends
Previous Message Bertrand Drouvot 2025-08-04 07:51:58 Re: Missing import in 035_standby_logical_decoding.pl