(I'm the original reporter).
I think this gets to the crux of the matter, although I disagree that no
bug exists.
ISBN10s, i.e. 10-digit ISBNs, can be converted to ISBN13s, and back again.
i.e. they round-trip. ISBN13s with the 979 prefix can't be converted to
ISBN10s. (Evidence includes http://pcn.loc.gov/isbncnvt.html failing on
ISBN13s with 979- prefixes with "This 13-digit ISBN does not begin with
"978"
It cannot be converted to a 10-digit ISBN.", and
https://247pearsoned.custhelp.com/app/answers/detail/a_id/6922/~/isbn-converter
stating "The revised ISBN standard does not provide rules for converting or
assigning 10-digit ISBNs to 13-digit ISBNs prefixed with "979". There is no
industry approved method for converting ISBN-13s prefixed with "979" to an
ISBN-10. Thirteen-digit ISBNs prefixed with "979" should not be represented
to trading partners as 10-digit ISBNs. ").
The key bug, then, is that the isn extension attempts to make this illegal
conversion:
select '9791020902573'::isbn; --gives 10-209-0257-4
I suspect the correct behaviour is raising an exception in these
circumstances.
