pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
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?
Date: Sun, 11 Jan 2026 15:50:19 +0800
Message-ID: <aWNWO8wEvu6YQaKN@jrouhaud> (raw)
In-Reply-To: <928501.1766593260@sss.pgh.pa.us>
References: <aUwKEWGge5jWtaRX@jrouhaud>
	<928501.1766593260@sss.pgh.pa.us>

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.





view thread (19+ messages)  latest in thread

Message-ID: <aWNWO8wEvu6YQaKN@jrouhaud>
Permalink:  ../aWNWO8wEvu6YQaKN@jrouhaud/
Also on:    postgresql.org/message-id/aWNWO8wEvu6YQaKN@jrouhaud

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: rjuju123@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
  Subject: Re: Cleaning up PREPARE query strings?
  In-Reply-To: <aWNWO8wEvu6YQaKN@jrouhaud>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox