Re: ISN was: Core Extensions relocation

On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus <josh(at)agliodbs(dot)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