Re: TRUE/FALSE vs true/false

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: TRUE/FALSE vs true/false
Дата
Msg-id 1344999428.17599.6.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: TRUE/FALSE vs true/false  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: TRUE/FALSE vs true/false
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: superusers are members of all roles?
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: [HACKERS] PL/Perl build problem: error: ‘OP_SETSTATE’ undeclared