From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib vs. gborg/pgfoundry for replication solutions |
Date: | 2004-04-21 23:07:01 |
Message-ID: | 20040421200023.X32445@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 21 Apr 2004, Tom Lane wrote:
> No, those guys are exactly the sort of backend-dependent code I'm
> thinking of. Teodor just recently made a GIST API change that affected
> both the core backend and tsearch (as well as the other GIST modules in
> contrib). With separate distribution trees that would've been a lot
> more painful to do.
>
> I think the long-term plan for tsearch2, at least, should be full
> integration rather than separation ...
But there should be some sort of path to full integration ...
isdb_ibbn(sp?) has been there forever, and I canj't see it ever being
integrated ...
Personally, the neat thing about PostgreSQL is that we are extendible(sp?)
quite easily, and stuff like tsearch, earthdistance, postgis, etc all show
that very nicely ... why add for the sake of adding?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-04-21 23:16:35 | Re: contrib vs. gborg/pgfoundry for replication solutions |
Previous Message | Josh Berkus | 2004-04-21 22:34:20 | Re: contrib vs. gborg/pgfoundry for replication solutions |