Re: Cleaning up PREPARE query strings?

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)

In response to

Browse pgsql-hackers by date

  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