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 по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: [HACKERS] [bug fix] Trivial ecpg bug which can cause memoryoverrun
Следующее
От: tushar
Дата:
Сообщение: Re: [HACKERS] Parallel Index Scans