Horton

Re: ISN was: Core Extensions relocation

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2011-11-16T00:46:01Z
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

On 15 November 2011 23:57, Robert Haas <robertmhaas@gmail.com> wrote:
> We can't go on complaining one the one hand that
> people don't install postgresql-contrib, and then on the other hand
> insist on shipping really bad code in contrib.  It's asking a lot for
> someone who isn't already heavily involved in the project to
> distinguish the wheat from the chaff.

ISTM that any sensible sanitisation of data guards against Murphy, not
Machiavelli. Exactly what sort of error is it imagined will be
prevented by enforcing that ISBN prefixes are "valid"? Transcription
and transposition errors are already guarded against very effectively
by the check digit.

If we can't put isn out of its misery, a sensible compromise would be
to rip out the prefix enforcement feature so that, for example, ISBN13
behaved exactly the same as EAN13. That would at least result in
predictable behaviour. The "strike" that separates each part of the
ISBN would be lost, but it is actually not visible on large ISBN
websites, presumably because it's a tar-pit of a problem.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services