From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Subject: | Re: Review of: pg_stat_statements with query tree normalization |
Date: | 2012-01-16 23:53:34 |
Message-ID: | 21878.1326758014@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-01-16 23:58:24 | Re: Review of: pg_stat_statements with query tree normalization |
Previous Message | Greg Smith | 2012-01-16 23:43:26 | Re: Review of: pg_stat_statements with query tree normalization |