> 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)
v4-0001-Clean-up-PREPARE-query-strings-in-multi-statement.patch
Description: Binary data
