>> 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.
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?
> That's exactly why contrib is a random amalgamation of really useful
> stuff and utter crap: people feel justified in defending the continued
> existence of the crap on the sole basis that it's useful to them
> personally.
Why else would we justify anything? It's very difficult to argue on the
basis of theoretical users. How would we really know what a theoretical
user wants?
Calling something "crap" because it has a spec issue is unwarranted.
We're going to get nowhere in this discussion as long as people are
using extreme and non-descriptive terms.
The thing is, most of the extensions in /contrib have major flaws, or
they would have been folded in to the core code by now. CITEXT doesn't
support multiple collations. INTARRAY and LTREE have inconsistent
operators and many bugs. CUBE lacks documentation. DBlink is an
ongoing battle with security holes. etc.
Picking out one of those and saying "this is crap because of reason X,
but I'll ignore all the flaws in all these other extensions" is
inconsistent and not liable to produce results. Now, if you wanted to
argue that we should kick *all* of the portable extensions out of
/contrib and onto PGXN, then you'd have a much stronger argument.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com