Re: The reasoning behind having several features outside of source?
От | Chris Browne |
---|---|
Тема | Re: The reasoning behind having several features outside of source? |
Дата | |
Msg-id | 60r7nhpay9.fsf@dba2.int.libertyrms.com обсуждение исходный текст |
Ответ на | The reasoning behind having several features outside of source? (nd02tsk@student.hig.se) |
Список | pgsql-general |
nd02tsk@student.hig.se writes: > Why is it that PostgreSQL chooses to have features like replication, > fulltext indexing and GIS maintained by others outside of the sourcetree? > > I appreciate any answers. Part of the answer is that "there are many answers." As Jan Wieck will mention, there are multiple substantially different models of what "replication" means, not just one. It is possible that one answer might prove sufficiently widely usable as to become ubiquitous, but there is also a problem with putting it in the source tree, in that a replication "solution" intended to be usable on multiple versions of PostgreSQL makes it painful to put it in the tree since it needs to be maintainable independently of any given PostgreSQL source tree. That last bit is true for many kinds of features. Anything that needs to be independent of PostgreSQL versions needs to be maintained "somewhere else." One thing that has been coming into place in 7.4 and 8.x is the ability to have a source tree that has enough there amongst the installed include files and libraries to make it increasingly "less difficult" (it may still only be "more easy" to masochists!) to compile things for PostgreSQL without needing a whole source tree. As that stabilizes, that makes it more and more sensible to throw things OUT of the source tree if they don't _absolutely_ need to be there. A relevant challenge with Slony-I, at this point, is that it needs a PG source tree, at present, in order to compile. Which is a serious irritation to anyone trying to build binary packages ala RHAT .rpm files and such; their "build system" will therefore require building PG from scratch in order to build a Slony-I package. And if there's something else that needs PG sources, say a GIS module, building .rpms for it would also require building PG from scratch, separately from the "build from scratch" required for Slony-I. Ten add-ons might mean ten source tree builds, which is NOT a good thing! The "pgxs" extension system hopes to solve that. -- let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];; http://www.ntlug.org/~cbbrowne/linuxxian.html A VAX is virtually a computer, but not quite.
В списке pgsql-general по дате отправления: