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