Re: Raw parse tree is not dumped to log - Mailing list pgsql-hackers

From Chao Li
Subject Re: Raw parse tree is not dumped to log
Date
Msg-id CAEoWx2=3c_=EomnwbSemR=F1t9spySdoQhN5e-Y30kPeBwmWiQ@mail.gmail.com
Whole thread Raw
In response to Re: Raw parse tree is not dumped to log  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Raw parse tree is not dumped to log
List pgsql-hackers
Oh, I forget to attached the patch file, here comes it.

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


Chao Li <li.evan.chao@gmail.com> 于2025年8月4日周一 15:53写道:
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.evan.chao@gmail.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@postgresql.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
Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Improve LWLock tranche name visibility across backends
Next
From: JiaoShuntian
Date:
Subject: GB18030-2022 Support in PostgreSQL