Re: Cleaning up PREPARE query strings?

> It's hard to know what changed exactly as you show the diff against master

Here it is as a v4

> 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,

From what I can tell, executor_errposition is difficult to trigger in
practice due to
commit 0436f6bde8 and the related discussion in [1]. Most errors now occur
during parsing analysis rather than execution.

Therefore, in the attached v4 patch, I propose NOT passing the cleaned
up text to
pg_analyze_and_rewrite_varparams() as v3 does:

- query_list = pg_analyze_and_rewrite_varparams(rawstmt,
pstate->p_sourcetext,
+ query_list = pg_analyze_and_rewrite_varparams(rawstmt, new_query,

Instead, continue passing the original source text (pstate->p_sourcetext).
This ensures that parser_errposition() uses cursor marker position relative
to the original multi-statement string.

Also, from what I can see, in the cases where executor_errposition()
is triggered
(though I don't have a test case), those will use the cleaned-up source text
from the plan cache. However, the prepared statement must be executed
via EXECUTE, so the cursor marker position is not a concern in this case.

[1] [https://www.postgresql.org/message-id/27103.1496979469%40sss.pgh.pa.us]

--
Sami Imseih
Amazon Web Services (AWS)