Re: pg_stat_statements: Fix normalization of + signs for FETCH and MOVE

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>
Subject: Re: pg_stat_statements: Fix normalization of + signs for FETCH and MOVE
Date: 2026-06-01 07:53:11
Message-ID: C51EB1B2-82C1-4ED3-87B1-2A17D80F46C2@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Jun 1, 2026, at 14:06, Michael Paquier <michael(at)paquier(dot)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 was misleading, so I have updated it.

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

Attachment Content-Type Size
v2-0001-pg_stat_statements-Fix-normalization-of-signs-for.patch application/octet-stream 5.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2026-06-01 07:57:39 Re: Eager aggregation, take 3
Previous Message Peter Smith 2026-06-01 07:28:53 Re: Support EXCEPT for TABLES IN SCHEMA publications