On Wed, 2007-01-24 at 19:15 +0100, Peter Eisentraut wrote:
> Teodor Sigaev wrote:
> > If there aren't objections then we plan commit patch tomorrow or
> > after tomorrow.
>
> I still haven't heard any argument for why this would be necessary or
> desirable at all, other than that it looks better for marketing
> reasons, which I will counter by saying that it looks worse for
> marketing reasons because our hailed plugin mechanism is apparently so
> poor that it can't support some practical extension module such as
> this.
>
On that point, why do we have /contrib? It's for "plugins" that are so
version-dependent that they can't exist as a separate project, as I
understand it.
But what we want when we say we have a plugin mechanism is something
more like CPAN, where software is developed on it's own timeline and can
be added seamlessly into any version of PostgreSQL that supports the
needs of the project.
PostGIS is a good example of this. You don't have to wait for a
PostgreSQL release to upgrade PostGIS, and they don't have to discuss
the intricacies of spatial queries and data on -hackers.
If tsearch2 really does need to be in lockstep with the PostgreSQL
releases (although I don't see why it does), I don't see a problem
putting it in core. It's an important feature, and we're already giving
up a lot of the benefits of plugins anyway by distributing it with the
project.
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
