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