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
