Re: contrib vs. gborg/pgfoundry for replication solutions
От | Tom Lane |
---|---|
Тема | Re: contrib vs. gborg/pgfoundry for replication solutions |
Дата | |
Msg-id | 14857.1082576946@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: contrib vs. gborg/pgfoundry for replication solutions ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: contrib vs. gborg/pgfoundry for replication solutions
|
Список | pgsql-hackers |
"Marc G. Fournier" <scrappy@postgresql.org> writes: > On Wed, 21 Apr 2004, Tom Lane wrote: >> "Joshua D. Drake" <jd@commandprompt.com> writes: >>> My personal opinion is that contrib should be removed entirely. >> >> That's not real workable for code that is tightly tied to the backend, >> such as the various GIST index extensions presently in contrib. It's >> just easier to maintain that code when it's in with the backend. > tsearch, I believe, is maintained somewhere else already, no? same with > tsearch2? 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 ... regards, tom lane
В списке pgsql-hackers по дате отправления: