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