Re: ISN patch that applies cleanly with git apply

From: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Jan Otto <asche(at)me(dot)com>
Subject: Re: ISN patch that applies cleanly with git apply
Date: 2010-10-18 17:08:56
Message-ID: AANLkTimw_B0GMKQn6vjQRQ7B5nkFBxXj0zs2N_V3NOV-@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18 October 2010 16:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Personally I was hoping for some independent validation that the
> proposed changes match current reality in ISN-land.  But apparently
> no one actually wants to repeat the research, so we might as well just
> take the changes on faith.

I'm not at all sure what that sort of independent validation would
look like. I thought I might be able to use some REST API or something
to fetch a bunch of recent ISBNs and validate the hyphenation against
that. After all, there isn't any fundamentally better way of
validating the ISBNs, as new ranges aren't created according to some
fixed scheme....they're allocated based on demand by regional
authorities, who probably act quite autonomously.

There is such a REST API available, from http://isbndb.com, but they
had the good sense to not try and hyphenate their ISBNs :-)

>> Actually, we just use the range information to hyphenate ISBNs...they
>> won't actually be rejected unless they have an invalid check digit,
>> or, in the case of ISBN-13s, if their country codes (first 3 digits)
>> aren't "bookland", either 978 or 979. Perhaps the problem of new
>> ranges being introduced over time isn't all that much of a problem.
>
> Yeah, in the real world this is not all that important.

Which is why no one will ever do what I've suggested with the
untrusted pl function...no one cares enough about hyphenation. It took
this long for this patch to be produced. For what it's worth, I don't
think we should be hyphenating at all.

>> Could this patch be backported as a bug fix?
>
> This isn't a bug fix in my opinion.  It's a behavioral change, and one
> with nonzero risk of breaking apps that might not expect the new
> hyphenation.

I think that the chance of it breaking an app is vanishingly small,
and I think that that should be good enough. Prior to the patch, the
ISBN wouldn't have been hyphenated - we would have fallen back on not
hyphenating it at all. I really cannot imagine why someone would rely
on a certain unrecognised range of ISBNs not being hyphenated.

>> It adds the new bookland
>> country code of 979. Prior versions of the patch will outright reject
>> these correct ISBN-13s, so I think that is a good idea.
>
> Hm, maybe just the addition of 979 is ok to back-port.  Comments?

If you're not going to backport everything, I think that that's reasonable.

--
Regards,
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-18 17:12:10 Re: Floating-point timestamps versus Range Types
Previous Message Pavel Stehule 2010-10-18 17:07:08 Re: string function - "format" function proposal