Date: Sun, 1 Mar 2026 08:10:27 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Subject: Re: Cleaning up PREPARE query strings?
Message-ID: <aaOD8_Q7qp3OwFJn@jrouhaud>
References: <aWbMU6wKpYkJHPP5@jrouhaud>
 <CAA5RZ0s4UPJ5uHzcfDqOLOskOFTPFZnUZwZS7e93LTmG8nHVnA@mail.gmail.com>
 <aWhv-ZXEJ3kd-dWa@jrouhaud>
 <CAA5RZ0sHJ2D2vdhH4nnUVuZKfSqpaywPeP98C9-LkGKG2rPSYg@mail.gmail.com>
 <aWzBasMzcQDjFSSe@jrouhaud>
 <CAA5RZ0sU-XUaGAATHhNZ-85u5h8SSbw0ykBPdBjOK-YXQkoy6g@mail.gmail.com>
 <aW2D2NJyC6hqym0I@jrouhaud>
 <CAA5RZ0tO7KXtOSGLGzhGijneTs5+v32PqOxhQ0bSj9Q8stLPyw@mail.gmail.com>
 <aXYTOw_1GXq0oMaq@jrouhaud>
 <CAA5RZ0vgcfJHVdGkjeeG=Ft_Tf5GCNECE2FLkPCWp3E-EppP2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0vgcfJHVdGkjeeG=Ft_Tf5GCNECE2FLkPCWp3E-EppP2g@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aaOD8_Q7qp3OwFJn%40jrouhaud>
Precedence: bulk

Hi,

On Mon, Jan 26, 2026 at 04:48:59PM -0600, Sami Imseih wrote:
> > This was already reported by Tom Lane on his first message, although his
> > complaint was about execution time error reporting while this is during
> > parse-analysis.  However, I think that the exact same approach can be used to
> > fixed both, either updating the position of every single element (which no one
> > wants) or teaching the executor (and evidently the planstate) about a new
> > "query offset" so that parser_errposition and executor_errposition report the
> > correct location.
>
> Maybe this is what you also mean, but I think it should be enough to
> just tell Query
> about the updated location = 0, and we don't need to touch anything else
> ( the raw parestree or the copy of it in plansource ). This will
> ensure that the error
> tracking is relying on the original raw parsetree, and consumers of the updated
> statement query location and lengths are getting the updated values based on
> the cleaned up query text that is stored in prepared statements.
>
> I tested the below with the tests you have in v3 so far and it works.
> I also tested
> the error position and it looks correct.
>
> Not sure if I am missing something.

It's hard to know what changed exactly as you show the diff against master
rather than against the patch, but IIUC the problem will be for execution time
error location reporting, as reported before.  I think that it will still be
wrong, but may now also point to an offset that isn't in the query text.  I
still haven't been able to hit that code path, so I can't really investigate
more.  In general I feel like it would be cleaner to have the same handling for
a possible "location vs query offset" approach for both pare-analysis and
execution, but I'm not opposed to this approach if it gets the feature
accepted.