Horton
Menu

Thread

  1. Fixes a trivial bug in dumped parse/query/plan trees

    Chao Li <li.evan.chao@gmail.com> — 2025-08-25T00:54:43Z

    Hi Hackers,

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

```
  :sort.numCols 2
  :sort.sortColIdx ( 1 4)
  :sort.sortOperators ( 97 1754)
  :sort.collations ( 0 0)
  :sort.nullsFirst ( false false)
```

The unnecessary whitespace is now removed.

Regard regards,

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



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

    Stepan Neretin <slpmcf@gmail.com> — 2025-08-25T03:20:19Z

    On Mon, Aug 25, 2025 at 7:55 AM Chao Li <li.evan.chao@gmail.com> wrote:

> Hi Hackers,
>
> This patch fixes a trivial bug where an extra whitespace was added
> when dumping an array, for example:
>
> ```
>   :sort.numCols 2
>   :sort.sortColIdx ( 1 4)
>   :sort.sortOperators ( 97 1754)
>   :sort.collations ( 0 0)
>   :sort.nullsFirst ( false false)
> ```
>
> The unnecessary whitespace is now removed.
>
> Regard regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
Hi Chao,

I was able to reproduce the problem using a small test:

```sql
SET debug_print_parse = on;

CREATE TABLE test_sort_example (
    id SERIAL PRIMARY KEY,
    col1 INT,
    col2 TEXT,
    col3 TEXT
);

INSERT INTO test_sort_example (col1, col2, col3) VALUES
(1, 'apple', 'zebra'),
(2, 'banana', 'yak'),
(3, 'cherry', 'xylophone'),
(4, 'date', 'wolf');

SELECT * FROM test_sort_example
ORDER BY col2 ASC, col3 ASC;
```

The extra whitespace in the array dump (e.g.,

```
:sort.numCols 2
:sort.sortColIdx ( 1 4)
:sort.sortOperators ( 97 1754)
:sort.collations ( 0 0)
:sort.nullsFirst ( false false)
```

) was indeed present before the patch.

After applying your patch, the issue is fixed, and the array is now dumped
correctly without extra spaces. The patch looks good to me.

Regarding testing: for this case, a Perl test might actually be more
suitable than SQL tests, because OIDs can change between runs and Perl
tests allow for better control and normalization of such values.

Best regards,
Stepan Neretin

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

    Chao Li <li.evan.chao@gmail.com> — 2025-08-25T03:59:22Z

    Hi Stepan,

Thanks for your testing.

> On Aug 25, 2025, at 11:20, Stepan Neretin <slpmcf@gmail.com> wrote:
> 
> 
> Regarding testing: for this case, a Perl test might actually be more suitable than SQL tests, because OIDs can change between runs and Perl tests allow for better control and normalization of such values.
> 

Are you suggesting add a test case to this patch? Can you please be more specific?

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

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

    Daniel Gustafsson <daniel@yesql.se> — 2025-08-25T08:02:39Z

    > On 25 Aug 2025, at 02:54, Chao Li <li.evan.chao@gmail.com> wrote:
> 
> Hi Hackers,
> This patch fixes a trivial bug where an extra whitespace was added
> when dumping an array, for example:
> 
> ```
>   :sort.numCols 2
>   :sort.sortColIdx ( 1 4)
>   :sort.sortOperators ( 97 1754)
>   :sort.collations ( 0 0)
>   :sort.nullsFirst ( false false)
> ```
> 
> 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.)

--
Daniel Gustafsson

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

    Chao Li <li.evan.chao@gmail.com> — 2025-08-25T08:57:09Z

    
> On Aug 25, 2025, at 16:02, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
> 
> 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.)
> 
> 

The commit message says:

Let's adopt a format similar to that used for Lists, that is "<>"
for a NULL pointer or "(item item item)" otherwise. Also retool
the code to not have so many copies of the identical logic.

It mentioned “(item item item)”, not a whitespace in front of the first item.

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

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

    Chao Li <li.evan.chao@gmail.com> — 2025-08-27T01:35:07Z

    
> On Aug 25, 2025, at 16:57, Chao Li <li.evan.chao@gmail.com> wrote:
> 


Resending the patch file.

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



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

    Chao Li <li.evan.chao@gmail.com> — 2025-08-27T01:46:38Z

    Retry again to attach the path file.

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


Chao Li <li.evan.chao@gmail.com> 于2025年8月27日周三 09:35写道：

>
>
> On Aug 25, 2025, at 16:57, Chao Li <li.evan.chao@gmail.com> wrote:
>
>
> Resending the patch file.
>
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
>

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-02T16:08:27Z

    Daniel Gustafsson <daniel@yesql.se> writes:
>> On 25 Aug 2025, at 02:54, Chao Li <li.evan.chao@gmail.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