Re: Core Extensions relocation

Excerpts from Robert Haas's message of mar nov 15 15:03:03 -0300 2011:
> On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus <josh(at)agliodbs(dot)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.
> >> 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.

Interesting. Isn't it possible to separate it into two parts, one
containing generic input, formatting and check digits verification, and
another one that would do the prefix matching? Presumably, the first
part would still be useful without prefix validation, wouldn't it?
Surely the other validation rules aren't different for the various
prefixes.

Perhaps the prefix matching code should not be in C, or at least use a
lookup table that's not in C code, so that it can be updated in userland
without having to recompile. (BTW, this is very similar to the problem
confronted by the E.164 module, which attempts to do telephone number
validation and formatting; there's a generic body of code that handles
the basic country code validation, but there's supposed to be some
per-CC formatting rules which we're not really clear on where to store.
We punted on it by just having that in a GUC, so that the user can
update it easily; but that's clearly not the best solution).

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support