>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers