Re: Core Extensions relocation - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Core Extensions relocation
Date
Msg-id 4EC2608B0200002500042F67@gw.wicourts.gov
Whole thread Raw
In response to Re: Core Extensions relocation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Joshua Berkus <josh@agliodbs.com> wrote:
>>> I consider contrib/isn to be quite broken. It hard codes ISBN
>>> prefixes for the purposes of sanitising ISBNs, even though their
>>> assignment is actually controlled by a decentralised body of
>>> regional authorities.
By an international standard which says what numbers are valid in
the "prefix element" and "registration group element" of the ISBN
for each of those regional authorities, and how the check digit is
to be calculated.
>>> I'd vote for kicking it out of contrib.
>>
>> Submit a patch to fix it then.
> 
> It's not fixable.  The ISBN datatype is the equivalent of having
> an SSN datatype that only allows SSNs that have actually been
> assigned to a US citizen.
Certainly it would make sense to go so far as to support the overall
standard format as described here:
http://www.isbn-international.org/faqs/view/5#q_5
Beyond the broad strokes there, perhaps it would make sense for the
type to be able to digest a RangeMessage.xml file supplied by the
standards organization, so that the current ranges could be plugged
in as needed independently of the PostgreSQL release.
http://www.isbn-international.org/page/ranges
http://www.isbn-international.org/pages/media/Range%20message/RangeMessage.pdf
Hard-coding ranges as of some moment in time seems pretty dubious.
-Kevin


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Core Extensions relocation
Next
From: Christopher Browne
Date:
Subject: Re: [PATCH] Unremovable tuple monitoring