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 g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
