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