Re: TRUE/FALSE vs true/false

On Thu, Aug 16, 2012 at 3:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Aug 16, 2012 at 02:21:12PM -0500, Kevin Grittner wrote:
>> Bruce Momjian <bruce(at)momjian(dot)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