Re: pg_stat_statements: Fix normalization of + signs for FETCH and MOVE - Mailing list pgsql-hackers

> On Jun 1, 2026, at 14:06, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Jun 01, 2026 at 01:33:40PM +0800, Chao Li wrote:
>> As shown above, the "+" sign is replaced separately from the
>> integer. However, a "-" sign is handled correctly:
>> ```
>> We just need to handle "+" in the same way. See the attached patch for details.
>
> This is not directly related to FETCH and MOVE.  For example:
> =# select +1;
> ?column?
> ----------
>        1
> (1 row)
> =# select query from pg_stat_statements where query ~ 'select';
>   query
> ------------
> select +$1
> (1 row)
>
> I don't recall somebody complaining about that..
> --
> Michael

Thanks for pointing out the example. I don’t think “select +1” parse “+” in the same way as a FETCH statement.

If we turn on debug_print_raw_parse:
```
evantest=*# set debug_print_raw_parse = 1 and check the raw parse trees:
SET
evantest=*# select +1;
 ?column?
----------
        1
(1 row)
```

This generates a raw parse tree containing:
```
2026-06-01 15:05:08.528 CST [22501] DETAIL:  (
       {RAWSTMT
       :stmt
          {SELECTSTMT
          :distinctClause <>
          :intoClause <>
          :targetList (
             {RESTARGET
             :name <>
             :indirection <>
             :val
                {A_EXPR
                :name ("+")
                :lexpr <>
                :rexpr
                   {A_CONST
                   :val 1
                   :location 8
                   }
                :rexpr_list_start 0
                :rexpr_list_end 0
                :location 7
                }
             :location 7
             }
          )
```

Here, “+” is parsed as a unary operator, A_EXPR’s location is at “+”, and A_CONST’s location is at “1”.

For a FETCH statement:
```
evantest=*# fetch +1 c;
 g
---
 4
(1 row)
```

The raw parse tree looks like:
```
2026-06-01 15:05:37.993 CST [22501] DETAIL:  (
       {RAWSTMT
       :stmt
          {FETCHSTMT
          :direction 0
          :howMany 1
          :portalname c
          :ismove false
          :direction_keyword 0
          :location 6
          }
       :stmt_location 0
       :stmt_len 10
       }
    )
```

Here, the count is parsed through SignedIconst, and the FETCHSTMT location is at “+".

So, I still think this issue is specific to FETCH and MOVE. However, I realized that the new code comment in my patch
wasmisleading, so I have updated it. 

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