On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus <j...@agliodbs.com> wrote: >>> 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. > > Nothing is "not fixable". "not fixable without breaking backwards > compatibility" is entirely possible, though. If fixing it led to two > different versions of ISN, then that would be a reason to push it to > PGXN instead of shipping it.
Well, the way to fix it would be to publish a new version of PostgreSQL every time the international authority that assigns ISBN prefixes allocates a new one, and for everyone to then update their PostgreSQL installation every time we do that. That doesn't, however, seem very practical. It just doesn't make sense to define a datatype where the set of legal values changes over time. The right place to put such constraints in the application logic, where it doesn't take a database upgrade to fix the problem. > It's not as if ISN is poorly coded. This is a spec issue, which must > have been debated when we first included it. No? I think our standards for inclusion have changed over the years - a necessary part of project growth, or we would have 500 contrib modules instead of 50. The original isbn_issn module was contributed in 1998; it was replaced by contrib/isn in 2006 because the original module became obsolete. I think it's fair to say that if this code were submitted today it would never get accepted into our tree, and the submitter would be advised not so much to publish on PGXN instead as to throw it away entirely and rethink their entire approach to the problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers