Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> Additionally, what problem is accepting incremental patches supposed
> to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining is something like what I did a year or two back when
I wanted to make the executor treat plan trees as read-only --- if
memory serves, I did that in three or four commits spread over a week or
two. I could have done it in one massive patch but it would have been
unreadable to me or anyone else. And for that matter, the reason for
doing it at all was as part of a much larger concept that's still
unfinished (better caching and invalidation of plans). When you're
talking about tasks of that magnitude, stepwise improvement is the only
way you are going to get there at all.
I really don't have any faith in the concept of doing very large tasks
on a development branch and expecting to land them in one huge merge.
For a nearby counterexample look at Postgres-R, which never has and
probably never will manage to produce a patch that could apply to the
core project's CVS head. At least not without thinking of some
incremental way to do it, because by the time they bring all their
changes up to HEAD, the tree has always drifted under them. There is
no magic version control system that will fix that.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
