Re: Cleaning up PREPARE query strings?

Hi,

On Mon, Jan 19, 2026 at 12:43:53AM -0600, Sami Imseih wrote:
>
> However, the error reporting does break with the patch. Notice with the patch
> the cursor for the error reporting shifts incorrectly. This is due to the fact
> rawstmt->stmt_location/length are no longer representative of the original
> qurey text.
>
> ## unpatched
> ```
> postgres=# SELECT 1    \; PREPARE stmt AS SELECT nonexistent_column
> FROM users\; SELECT 2;
>  ?column?
> ----------
>         1
> (1 row)
>
> ERROR:  relation "users" does not exist
> LINE 1: ... ; PREPARE stmt AS SELECT nonexistent_column FROM users; SEL...
>
>                                        ^
> ```
>
> ## patched
> ```
> postgres=# SELECT 1    \; PREPARE stmt AS SELECT nonexistent_column
> FROM users\; SELECT 2;
>  ?column?
> ----------
>         1
> (1 row)
>
> ERROR:  relation "users" does not exist
> LINE 1: ...LECT 1    ; PREPARE stmt AS SELECT nonexistent_column FROM u...
>
>                                    ^
> ```

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.  I'm still waiting on whether the latter would be acceptable
or not before implementing it.  Note that I wasn't able to hit the execution
time error so at least with parse-analysis time error I could at least have
some regression tests, so thanks a lot!

In the meantime, the cfbot shows that a rebase is needed, so v3 attached.