Re: TRUE/FALSE vs true/false - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: TRUE/FALSE vs true/false
Date
Msg-id 1344999428.17599.6.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: TRUE/FALSE vs true/false  (Bruce Momjian <bruce@momjian.us>)
Responses Re: TRUE/FALSE vs true/false
List pgsql-hackers
On Tue, 2012-08-14 at 17:36 -0400, Bruce Momjian wrote:
> On Tue, Aug 14, 2012 at 05:34:02PM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > On Thu, Aug  4, 2011 at 09:00:11PM +0300, Peter Eisentraut wrote:
> > >> On tor, 2011-08-04 at 14:44 +0200, Boszormenyi Zoltan wrote:
> > >>> I meant a mass "sed -e 's/TRUE/true/g'  -e 's/FALSE/false/g'" run
> > >>> so all the ~200 occurrences of both "TRUE" and "FALSE" get
> > >>> converted so the whole source tree is consistent.
> > 
> > >> I would be in favor of that.
> > 
> > > I have implemented this with the patch at:
> > >     http://momjian.us/expire/true_diff.txt
> > 
> > Does this really do anything for us that will justify the extra
> > back-patching pain it will cause?  I don't see that it's improving
> > code readability any.
> 
> I think it is more of a consistency issue.  There were multiple people
> who wanted this change.  Of course, some of those people don't backport
> stuff.

I guess you could argue this particular case without end, but I think we
should be open to these kinds of changes.  They will make future code
easier to deal with and confuse new developers less (when to use which,
do they mean different things, etc.).

If back-patching really becomes a problem, we might want to look a
little deeper into git options.  I think the Linux kernel people do
these kinds of cleanups more often, so there is probably some better
support for it.




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: superusers are members of all roles?
Next
From: Alex Hunsaker
Date:
Subject: Re: [HACKERS] PL/Perl build problem: error: ‘OP_SETSTATE’ undeclared