Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> Btw., I would recommend that even in-progress or proposed patches
>> include catversion updates,
> I thought we had a policy of NOT doing that, because of the merge
> conflicts thereby created. It's also hard to know what value to set
> it to; whatever you pick will certainly be obsolete by commit time.
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 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.
Still, I can see the point of forcing an initdb when needed.
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. I'm not
personally going to rely on a submitter's determination of whether a
catversion bump is needed anyhow.
So I lean towards being happy with the current approach, though I could
be talked into the other given a better argument for it.
regards, tom lane