Horton

Re: Core Extensions relocation

Kevin Grittner <kevin.grittner@wicourts.gov>

View thread
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Joshua Berkus" <josh@agliodbs.com>, "Robert Haas" <robertmhaas@gmail.com>
Cc: "Peter Geoghegan" <peter@2ndquadrant.com>, <pgsql-hackers@postgresql.org>
Date: 2011-11-15T18:52:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Updates to contrib/isn ISBN tables.

  2. Add a "LIKE = typename" clause to CREATE TYPE for base types. This allows

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