2010/2/18 Tom Lane <tgl@sss.pgh.pa.us>:
> In connection with the recent discussion of changing SearchSysCache call
> format, Robert espoused the view that right now is the time when there
> are a minimal number of outstanding patches that would suffer merge
> problems from an invasive change. That seems correct to me --- although
> ideally everyone should be thinking "beta test" for the next few months,
> we all know there will be some development going on in people's private
> trees.
>
> Which leads me to the thought that rather than postponing running
> pgindent until late beta, maybe we should run it *now*, and get the
> bulk of its work done for the new code in 9.0. Then people would have
> a solid base to patch against, rather than having to expect a major
> merge hassle at the end of beta.
>
> We'd probably still want to run pgindent again at the traditional
> point in the cycle, but if we did one now then the final run would
> only be fixing sloppiness in beta-period fixes, and it should make
> relatively few changes.
>
> I have a personal interest in this because I'm hoping to spend time
> over the next few weeks reading all of the HS/SR code in detail, and
> it will be nicer to look at if it's formatted to project standards;
> which quite a lot of it is not at the moment.
>
> Comments?
I think it's a good idea in general. There are of course people out
there with patches *already* that will have problems with this, but
they'll have the problem eventually anyway. The only real stopper
there is if someone (Simon would be the most likelyi I guess?) has a
big fixup change queued up or so - but if someone does, we can just
postpone until right after that one...
The followup question is of course, what do we do with fixup patches
that land *after* this? Do we run pgindent once more later in the
cycle? That should be a fairly small run in that case, so it might be
worth doing it that way?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
