Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries
Дата
Msg-id 7688.1484334364@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> One thing that I'm not quite satisfied with is the business with
>> non-top-level RawStmt nodes in some utility statements. 
>> ...
>> So I'm now thinking that it might be better if the grammar produced
>> RawStmt only at top level, and anybody who calls pg_analyze_and_rewrite
>> on sub-sections of a utility statement has to cons up a RawStmt to put
>> at the top of the sub-query.

> Why not. The lazy programmer I am notices that there seems to be 6 
> instances, this is not too bad, some of which are already dealt with. The 
> RawStmt may not need to be allocated dynamically, a stack instance could 
> be enough.

Here's a v2 that does it like that.  It ends up being about 30 fewer lines
of code overall, despite there being four places that have to make ad-hoc
RawStmt nodes.  On the whole I feel like this is cleaner, although there's
room to argue that.  Still, the extra cruft is in places that I'm
suspicious are wrong anyway, as I noted.

            regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] plan_rows confusion with parallel queries
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Packages: Again