On 01/16/2012 06:19 PM, Alvaro Herrera wrote:
> 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.)
The way this was packaged up was for easier reviewer consumption, just
pull down the whole thing and run with it. I was already thinking that
if we've cleared the basics with a positive review and are moving more
toward commit, it would be better to have it split into three pieces:
-Core parsing changes
-pg_stat_statements changes
-Test programs
And then work through those in that order. Whether or not the test
programs even go into core as contrib code is a useful open question.
While Peter had a version of this that worked completely within the
boundaries of an extension, no one was really happy with that. At a
minimum the .length changes really need to land in 9.2 to enable this
feature to work well. As Daniel noted, it's a lot of code changes, but
not a lot of code complexity.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
