Re: Review of: pg_stat_statements with query tree normalization
От | Tom Lane |
---|---|
Тема | Re: Review of: pg_stat_statements with query tree normalization |
Дата | |
Msg-id | 21878.1326758014@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Review of: pg_stat_statements with query tree normalization (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Review of: pg_stat_statements with query tree normalization
Re: Review of: pg_stat_statements with query tree normalization |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Daniel Farina's message of dom ene 15 08:41:55 -0300 2012: >> Onto the mechanism: the patch is both a contrib and changes to >> Postgres. The changes to postgres are mechanical in nature, but >> voluminous. The key change is to not only remember the position of >> Const nodes in the query tree, but also their length, and this change >> is really extensive although repetitive. > I wonder if it would make sense to split out those changes from the > patch, including a one-member struct definition to the lexer source, > which could presumably be applied in advance of the rest of the patch. > That way, if other parts of the main patch are contentious, the tree > doesn't drift under you. (Or rather, it still drifts, but you no longer > care because your bits are already in.) Well, short of seeing an acceptable patch for the larger thing, I don't want to accept a patch to add that field to Const, because I think it's a kluge. I'm still feeling that there must be a better way ... regards, tom lane
В списке pgsql-hackers по дате отправления: