Re: Fixes a trivial bug in dumped parse/query/plan trees

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fixes a trivial bug in dumped parse/query/plan trees
Date: 2025-09-02 16:08:27
Message-ID: 594270.1756829307@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 25 Aug 2025, at 02:54, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> This patch fixes a trivial bug where an extra whitespace was added
>> when dumping an array, for example:
>> ...
>> The unnecessary whitespace is now removed.

> What about external parsers written for this format which might now break?
> (Judging by the commitlog I believe this format is intentional and not a bug.)

Yeah, I'm inclined to reject this patch. This is by no stretch of the
imagination a "bug"; a more accurate characterization is that it's a
minor optimization that the original author did not think was worth
troubling with. While our existing nodeRead code wouldn't have a
problem with removing the extra whitespace, I share your fear that
we could introduce bugs into some third-party code somewhere.
So the cost/benefit ratio of making the change doesn't look very good
to me.

I do have interest in trying to aggressively reduce the stored size
of view/rule parsetrees, and would be willing to break such
hypothetical third-party code in pursuit of a sufficiently large
improvement (say, 2X or better). But a change like this one,
in isolation, isn't going to move that needle.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-09-02 16:42:54 Re: Get rid of pgstat_count_backend_io_op*() functions
Previous Message Nathan Bossart 2025-09-02 16:02:37 Re: Use bool with synced field (src/include/replication/slot.h)