Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Sat, Mar 24, 2018 at 11:14:34PM -0400, Tom Lane wrote: > > Stephen Frost <sfr...@snowman.net> writes: > >> I don't completely buy off on the argument that having these #define's > >> would make it easier for forks (we've had quite a few folks fork PG, but > >> how many of them have actually changed "base"?) and I'm on the fence > >> about if these will make our lives simpler down the road when it comes > >> to changing the directory names > > > > I am distressed that nobody, apparently, is putting any weight on the > > back-patching pain that will result from widespread replacement of path > > names with macros. I don't buy that either we or anyone else will need > > to change these names in future, so I see pain and effectively no > > gain.
While I agree that some consideration should be given to the impact a change has on back-patching, I continue to be of the opinion that this would be a good change, for the reasons which I outlined up-thread. That said, I don't hold that position very strongly. > That's actually something I worry about as well (as the author!), which > is why I qualify the changes as intrusive. At the end, I think that I > would be tempted to just do #3, aka to keep a copy of the filter list in > pg_rewind code while hardcoding a minimum of names and mention in both > basebackup.c and pg_rewind code to not forget to update the filter list > if necessary. New paths in the data folder are not added on a monthly > basis either, and not all of them can be filtered out so that's easy to > maintain. Intrusive, at least from my viewpoint, is more about how the code is changed around and/or refactored than about the impact it has on back-patching. These are pretty mechanical changes, after all. I'm not particularly thrilled with the idea of having two independent lists of hard-coded paths to maintain, even with comments in both places saying to update the other list. Thanks! Stephen
signature.asc
Description: PGP signature
