From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ISN was: Core Extensions relocation |
Date: | 2011-11-15 21:53:32 |
Message-ID: | 4421.1321394012@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Royce Ausburn | 2011-11-15 22:27:21 | Re: [PATCH] Unremovable tuple monitoring |
Previous Message | Nathan Boley | 2011-11-15 21:43:53 | Re: Collect frequency statistics for arrays |