Date: Sun, 11 Jan 2026 15:50:19 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Cleaning up PREPARE query strings?
Message-ID: <aWNWO8wEvu6YQaKN@jrouhaud>
References: <aUwKEWGge5jWtaRX@jrouhaud>
 <928501.1766593260@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <928501.1766593260@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/aWNWO8wEvu6YQaKN%40jrouhaud>
Precedence: bulk

Hi,

On Wed, Dec 24, 2025 at 11:21:00AM -0500, Tom Lane wrote:
> Julien Rouhaud <rjuju123@gmail.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'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).

Ah I wasn't aware of that.  After a quick look I'm assuming it's all the
callers of executor_errposition()?

There aren't a lot of them, and I've unfortunately been unable to hit any of
them.  Every scenario I tried was always caught during planning time.  Do you
have any example on how to exercise them?

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

I agree that updating the location fields in the whole parsetree is a non
starter, butt I don't think that it's the only option.

If that's indeed the cases going through executor_errposition(), they rely on
having the executor state at hand to retrieve the query string.   We could
simply have an extra "query string offset" field stored there that would always
be 0 except when PREPARE changes the input query string and then do the
location to character number calculation after applying that offset. And that
offset should already be returned by CleanQuerytext() so it wouldn't have extra
complication.