On tis, 2010-11-16 at 16:04 -0500, Tom Lane wrote:
> Well, my expectation would be that the committer would reset the
> catversion to current date when it goes into master. The question is
> whether such a practice would be (a) helpful to testers and/or (b)
> useful to the committer.
As with most such things, it's a matter of personal preference. I
started doing this out of necessity a while ago, and it has turned out
to be very helpful.
> As for (a), it likely would be, except that a patch that's not very
> recent is almost certainly going to get a merge failure here when the
> tester tries to apply it locally. That doesn't really seem like a gain.
Arguably, it means that the patch should be updated. At least, it's a
warning sign to the reviewer.
> Still, I can see the point of forcing an initdb when needed.
Especially because it prevents novice patch reviewers from mixing
mismatching source and data directories and wasting time on obscure
"bugs".
> As for (b), I'm not sure I buy Peter's argument about a merge conflict
> on that being a helpful flag. I don't see any reason to think that
> system catalog changes are much more (or less) likely to result in
> hidden merge conflicts than any other type of change.
Actually, in a recent sample, the likelihood for a hidden merge conflict
in near 100% because different patches keep reassigning the same OID for
new database objects.
In addition, there is the Git philosophy argument that every branch
should stand on its own. If more than one person collaborates on a
branch for more than one week, all the original reasons for having the
catversion in the first place come back into play. And so while I do
not wish to be radical about requiring catversion updates in random
patches, we should recognize the possibility that catversion updates
outside of the mainline are reasonable.