On 26 February 2013 21:45, Peter Eisentraut <pete...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
