Re: Regression in statement locations
От | Sami Imseih |
---|---|
Тема | Re: Regression in statement locations |
Дата | |
Msg-id | CAA5RZ0u4wC8_fa2aHMv_wBGFVV+WK1T5ZymnHQHmAL6f0a-75Q@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Regression in statement locations
|
Список | pgsql-hackers |
> It is also possible that the regression is not coming from > 499edb0 but I do not see another obvious candidate. I used pg_stat_statements to repro the issue, and a bisect resulted in 499edb0 being the source of the regression. ``` select pg_stat_statements_reset(); set pg_stat_statements.track='all'; DO $$ DECLARE BEGIN EXECUTE 'CREATE TABLE do_table (weird_name INT); DROP table do_table'; END $$; select query from pg_stat_statements where not toplevel; ``` WITHOUT a semicolon at the end of the statements, as reported by David ``` EXECUTE 'CREATE TABLE do_table (weird_name INT); DROP table do_table'; ``` I can reproduce the issue query ------------------------------------------------------------- CREATE TABLE do_table (weird_name INT); DROP table do_table CREATE TABLE do_table (weird_name INT) (2 rows) WITH a semicolon at the end of the statements ``` EXECUTE 'CREATE TABLE do_table (weird_name INT); DROP table do_table;'; ``` I cannot reproduce the issue query ---------------------------------------- DROP table do_table CREATE TABLE do_table (weird_name INT) (2 rows) I am still not sure why this is the case, but wanted to share this for now. -- Sami Imseih Amazon Web Services (AWS)
В списке pgsql-hackers по дате отправления: