Re: Failure in commit_ts tap tests

From: David Bowen <dmb0317(at)gmail(dot)com>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failure in commit_ts tap tests
Date: 2017-01-21 20:03:21
Message-ID: CANO09fjqZih930SkTaH5mPZWDWLswxhpohfn293UkXeEEwdCJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

If the intent of the test is to compare strings, you should be using ne not
!=.

David Bowen

On Sat, Jan 21, 2017 at 10:38 AM, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
wrote:

>
>
> On Sat, Jan 21, 2017 at 9:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
>> > On Sat, Jan 21, 2017 at 9:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >> Hm, but what of the "null" value? Also, I get
>> >>
>> >> $ perl -e 'use warnings; use Test::More; ok("2017-01-01" != "null",
>> "ok");'
>> >> Argument "null" isn't numeric in numeric ne (!=) at -e line 1.
>> >> Argument "2017-01-01" isn't numeric in numeric ne (!=) at -e line 1.
>> >> ok 1 - ok
>>
>> > It declares the test as "passed", right?
>>
>> Oh! So it does. That is one darn weird behavior of the != operator.
>>
>>
> Indeed! See this:
>
> # first numeric matches, doesn't check beyond that
> $ perl -e 'if ("2017-23" != "2017-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> # first numeric doesn't match, operators works ok
> $ perl -e 'if ("2017-23" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # comparison of numeric with non-numeric, works ok
> $ perl -e 'if ("2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> # numeric on RHS, works ok
> $ perl -e 'if ("Foo" != "2018-24") {print "Not equal\n"} else {print
> "Equal\n"}'
> Not equal
>
> These tests show that the operator returns the correct result it finds a
> numeric value at the start of the string, either on LHS or RHS. Also, it
> will only compare the numeric values until first non-numeric character is
> found.
>
> # no numeric on either side
> $ perl -e 'if ("Fri 2017-23" != "Fri 2017-23") {print "Not equal\n"} else
> {print "Equal\n"}'
> Equal
>
> *# no numeric on either side, arbitrary strings declared as equal*
> $ perl -e 'if ("Fri 2017-23" != "Foo") {print "Not equal\n"} else {print
> "Equal\n"}'
> Equal
>
> These two tests show why we saw no failure earlier. If neither LHS or RHS
> string has a starting numeric value, the operator declares the arguments as
> equal, irrespective of their values. I tested the same with == operator and
> that also exhibits the same behaviour. Weird and I wonder how it's not a
> source of constant bugs in perl code (I don't use perl a lot, so may be
> those who do are used to either turning warnings on or know this already.
>
>
>>
>>
>> There's still the point that we're not actually exercising this script
>> in the buildfarm ...
>>
>
> Yes indeed.
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2017-01-21 20:15:47 Re: Checksums by default?
Previous Message Stephen Frost 2017-01-21 19:20:02 Re: Checksums by default?