Josh Berkus <j...@agliodbs.com> writes: > 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. There's a larger issue here, which is that a lot of the stuff in contrib is useful as (a) coding examples for people to look at, and/or (b) test cases for core-server functionality. If a module gets kicked out to PGXN we lose pretty much all the advantages of (b), and some of the value of (a) because stuff that is in the contrib tree at least gets maintained when we make server API changes. So the fact that a module has conceptual flaws that are preventing it from getting moved into core doesn't really have much to do with whether we should remove it, IMV. The big question to be asking about ISN is whether removing it would result in a loss of test coverage for the core server; and I believe the answer is yes --- ISTR at least one bug that we found specifically because ISN tickled it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers