On Thu, Aug 16, 2012 at 3:32 PM, Bruce Momjian <br...@momjian.us> wrote: > On Thu, Aug 16, 2012 at 02:21:12PM -0500, Kevin Grittner wrote: >> Bruce Momjian <br...@momjian.us> wrote: >> >> > So what do we want to do with this? I am a little concerned that >> > we are sacrificing code clarity for backpatching ease, but I don't >> > do as much backpatching as Tom. >> >> Well, if you back-patched this change, it would eliminate the issue >> for Tom, wouldn't it? Not sure if that's sane; just a thought. > > I would be worried about some instability in backpatching. I was > looking for an 'ignore-case' mode to patch, but I don't see it.
I have difficult believing that a change of this type, if implemented judiciously, is really going to create that much difficulty in back-patching. I don't do as much back-patching as Tom either (no one does), but most of the patches I do back-patch can be cherry-picked all the way back without a problem. Some require adjustment, but even then this kind of thing is pretty trivial to handle, as it's pretty obvious what happened when you look through it. The really nasty problems tend to come from places where the code has been rearranged, rather than simple A-for-B substitutions. I think the thing we need to look at is what percentage of our code churn is coming from stuff like this, versus what percentage of it is coming from other factors. If we change 250,000 lines of code per release cycle and of that this kind of thing accounts for 5,000 lines of deltas, then IMHO it's not really material. If it accounts for 50,000 lines of deltas out of the same base, that's probably more than can really be justified by the benefit we're going to get out of it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers