On 15 November 2011 19:01, Josh Berkus <josh@agliodbs.com> wrote:
> Nothing is "not fixable".
My idea of fixing contrib/isn would be to remove so much of it that it
would obviously make more sense to use simple, flexible SQL. It simply
makes way too many assumptions about the user's business rules for a
generic C module.
> 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.
It is warranted, because contrib/isn is extremely wrong-headed.
> 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.
The difference is that it's possible to imagine a scenario under which
I could recommend using any one of those modules, despite their flaws.
I could not contrive a reason for using contrib/isn.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services