| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Cleaning up PREPARE query strings? |
| Date: | 2025-12-24 20:16:38 |
| Message-ID: | CAA5RZ0uco6Xxsgo6p8FakgRJjY3PhnjePWWmZWxJO2Sz6Xf=CA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I think this is a good idea.
> Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> > I'm attaching a POC patch to fix that behavior by teaching PREPARE to clean the
> > passed query text the same way as pg_stat_statements.
>
> This patch invalidates all the location fields in the parsed query:
> they could not be used to generate sane error cursors referencing the
> truncated string.
I am not sure why we need to update the location of the rawstmt at all.
CreateCachedPlan does not seem to care about location and length
of query strings, AFAICT.
```rawstmt->stmt_location = 0;```
This is somewhat tangential, but I am now also wondering if
CleanQuerytext itself
should not mess with supplied statement location and length, but instead
send back the location and length of the isolated query text within the
multi-line query separately.
From
```
extern const char *CleanQuerytext(const char *query, int *location, int *len);
```
To
```
extern const char *CleanQuerytext(const char *query, int location, int
len, int *new_location, int *new_len);
```
It looks wrong that CleanQueryText is modifying any of the original
locations and lengths.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2025-12-24 20:19:32 | Re: Fix and improve allocation formulas |
| Previous Message | Bruce Momjian | 2025-12-24 20:12:19 | Re: Docs: Standardize "cannot" usage in SGML source |