Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries |
Дата | |
Msg-id | alpine.DEB.2.20.1612220830070.3892@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] BUG: pg_stat_statements query normalization issueswith combined queries
|
Список | pgsql-hackers |
Hello Kyotaro-san, > [...] Agreed that copying statement string would be too much. But the > new *Stmt node should somehow have also the end location of the > statement since the user of a parse tree cannot look into another one. Yes. I was thinking of adding a "length" field next to "location", where appropriate. >> So I'm rather still in favor of my initial proposal, that is extend >> the existing location information to statements, not only some tokens. > > I thought that it's too much to let all types of parse node have > location but grepping the gram.y with "makeNode" pursuaded me to > agree with you. Indeed... > After changing all *Stmt nodes, only several types of nodes seems > missing it. Yes. I'll try to put together a patch and submit it to the next CF. -- Fabien.
В списке pgsql-hackers по дате отправления: