From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Cleaning up PREPARE query strings?
In-reply-to: <aUwKEWGge5jWtaRX@jrouhaud>
References: <aUwKEWGge5jWtaRX@jrouhaud>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Wed, 24 Dec 2025 23:43:13 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <928500.1766593260.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Dec 2025 11:21:00 -0500
Message-ID: <928501.1766593260@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/928501.1766593260%40sss.pgh.pa.us>
Precedence: bulk

Julien Rouhaud <rjuju123@gmail.com> writes:
> I'm attaching a POC patch to fix that behavior by teaching PREPARE to cl=
ean 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'm not sure how many places try to generate such
errors post-parsing, but it's more than zero, and I've long had
ambitions of trying to extend that substantially (e.g, allowing
execution-time errors from functions to point at the relevant function
call).

Certainly the patch could be extended to update all those fields,
but that increases its complexity very significantly.  I doubt
that it's worth it.  My reaction to your example is more like
"if that bothers you, don't do it that way".

			regards, tom lane