Re: Cleaning up PREPARE query strings?

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up PREPARE query strings?
Date: 2026-01-13 20:24:51
Message-ID: CAA5RZ0sswD2h2w8FkVjToA=3oNYUb1mW-zuCD=J6DDK2zuLuZg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I was looking a bit more here, and I found that this patch breaks if
pg_stat_statements is enabled.

```
postgres=# SELECT 'bingo'\; PREPARE q1 AS SELECT 1 AS a \; SELECT 42;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
!?>
```

This is because the raw statement location is set to 0 with the patch which
breaks generate_nromalized_query when trying to deal with a multi command
statement. So, I don't think the way v1 is doing things will actually work.

I am thinking that storing the statement length and location in the entry
of prepared_queries may be the better option. Having that info, the
cleaned up query text can be generated on the fly whenever
pg_prepared_statement is called.

We may not need to call CleanQuerytext whenever, however it does
have the benefit of removing leading and trailing whitespace and the
terminating semicolon.

What do you think?

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-01-13 20:26:02 Re: Enhancing Memory Context Statistics Reporting
Previous Message Robert Haas 2026-01-13 19:54:59 code contributions for 2025, WIP version