On 2015-05-31 11:55:44 -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > >> FYI, I realize that one additional thing that has discouraged code > >> reorganization is the additional backpatch overhead. I think we now > >> need to accept that our reorganization-adverse approach might have cost > >> us some reliability, and that reorganization is going to add work to > >> backpatching. > > > Actually, code reorganization in HEAD might cause backpatching to be > > more buggy, reducing reliability --- obviously we need to have a > > discussion about that. > > Commit 6b700301c36e380eb4972ab72c0e914cae60f9fd is a recent real example. > Not that that should dissuade us from ever doing any reorganizations, > but it's foolish to discount back-patching costs.
On the other hand, that code is a complete maintenance nightmare. If there weren't literally dozens of places that needed to be touched to add a single parameter, it'd be far less likely for such a mistake to be made. Right now significant portions of the file differ between the branches, despite primarily minor feature additions... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
