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