Regression in statement locations

Hackers,

499edb0 introduced more precise locations for nested statements. In 
general it works quite well and has made the pgAudit output much more 
readable -- so kudos for that.

However, I have noticed one regression in the pgAudit tests. We have 
this somewhat odd statement intentionally crafted for catch issues with 
logging:

--
-- Test obfuscated dynamic sql for clean logging
DO $$
DECLARE
	table_name TEXT = 'do_table';
BEGIN
	EXECUTE E'\t\n\r CREATE TABLE ' || table_name || E' ("weird name" 
INT)\t\n\r ; DROP table ' || table_name;
END $$;

In PG17 pgAudit logs the expected output:

NOTICE:  AUDIT: SESSION,35,2,DDL,CREATE 
TABLE,TABLE,public.do_table,"CREATE TABLE do_table (""weird name"" 
INT)",<none>
NOTICE:  AUDIT: SESSION,35,3,DDL,DROP TABLE,TABLE,public.do_table,DROP 
table do_table,<none>

But in PG18 we now get:

NOTICE:  AUDIT: SESSION,35,2,DDL,CREATE 
TABLE,TABLE,public.do_table,"CREATE TABLE do_table (""weird name"" 
INT)",<none>
NOTICE:  AUDIT: SESSION,35,3,DDL,DROP 
TABLE,TABLE,public.do_table,"CREATE TABLE do_table (""weird name"" INT)	

  ; DROP table do_table",<none>

The create table statement is fine but the drop table statement has 
create table glued to it. I tried removing the extra quotes, whitespace, 
etc. from our test and the result is the same.

I had a look through 499edb0 and did not see anything obvious. It is 
possible that I am missing a required change on my side but since the 
commit did not make any code changes to pg_stat_statements I do not 
think so. It is also possible that the regression is not coming from 
499edb0 but I do not see another obvious candidate.

Thoughts?

Thanks,
-David