On 26 February 2013 21:45, Peter Eisentraut <peter_e@gmx.net> wrote:
> Have each user create their custom domain?
That's likely to be the most effective solution, yes. I'd take the
fact that people haven't been complaining about contrib/isn more as
suggestive of people figuring this out for themselves than suggestive
of contrib/isn being of acceptable quality.
> Is there a stable subset that we could maintain with minimal effort?
Well, at the very least I'd rip out the over-zealous sanitisation
(everything but the check digit). I guess that enforcing the GS1
country codes within EAN-*s isn't completely crazy, if only because
new countries don't come along that often, and when they do that
doesn't tend to have anything to do with the dissolution of a GS1
member state.
Note that ISBN13 is just an EAN-13 from the fictional country of
bookland (that's a GS1 code). So for that reason, there arguably
doesn't need to be and shouldn't be a separate ISBN type. I guess
having a separate ISBN type was motivated solely by that enabling the
ill-advised additional sanitisation of ISBNs, though there is no
reason why you can't do something special with the bookland GS1 code
instead (nothing other than the fact that, as I've said, sanitising
what the module calls "ISBN_range" is generally quite a bad idea).
> Would it be better if the module were removed from PostgreSQL core but
> maintained externally where it can iterate faster and keep the database
> up to date?
I don't think so. To my mind, the whole idea of sanitising ISBN_range
stinks. GS1 country code sanitisation works out a lot better in
practice, but feels just as wrong to me. Check digit enforcement is
fine, even if that approach is a little bit limiting compared to a
custom domain.
Enforcing that a check digit must be correct gives you 99% of the
value that you're likely to get here, because it protects against
transposition errors, which are by far the most likely type of error
made by data entry clerks.
> Is there a third-party library that does maintain such a database so
> that this module could be based upon that instead of having to maintain
> the database itself?
No, there is not.
The textual representation of the types - the dashes - are fairly odd,
but it's too late to fix that.
--
Regards,
Peter Geoghegan