Re: Cleaning up PREPARE query strings? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Cleaning up PREPARE query strings?
Date
Msg-id aXYTOw_1GXq0oMaq@jrouhaud
Whole thread Raw
In response to Re: Cleaning up PREPARE query strings?  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Cleaning up PREPARE query strings?
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: "Jelte Fennema-Nio"
Date:
Subject: Re: RFC: adding pytest as a supported test framework
Next
From: David Rowley
Date:
Subject: Re: unnecessary executor overheads around seqscans