On Tuesday, June 16, 2015, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
> I think this definitely indicates a bug:
>>
>> regression=# select '9791020902573'::isbn;
>> isbn
>> ---------------
>> 10-209-0257-4
>> (1 row)
>>
>
> Yes, indeed, this one is definitely a bug.
>
> regression=# select '9791020902573'::isbn = '10-209-0257-4'::isbn;
>> ?column?
>> ----------
>> f
>> (1 row)
>>
>> so apparently the canonicalization conversion wasn't right to begin with.
>>
>
> I still do not get it, "False" is expected on this last one, as this is
> not the same book.
> I have no idea which of these forms should be considered valid or
>> canonical, but surely the two behaviors exhibited above are wrong.
>>
>
> I think that it is only the first one, i.e. converting the ISBN13 code
> beginning with 979 to a ISBN10 should have raised an exception.
>
>
There is only one problem/bug (hopefully) but it is evidenced by the fact
that the two queries provided contradict each other. It is basically a
different form of proof. You know the first query is wrong using external
knowledge but Tom has shown that a bug exists using strictly knowledge
local to the system. Without the external knowledge one cannot say which
alternative is correct but one must be incorrect.
Fixing the first query to become an error brings the system basic into
internal consistency since that result is congruous with the second query.
And is externally affirmed to be the correct outcome (I trust...).
Making the second query return true makes the system internally consistent
too...but doesn't actually provide the correct answer (again, I trust)
David J.