Re: [GENERAL] The reasoning behind having several features outside of source?
[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] The reasoning behind having several features outside of source?
On Mon, Oct 25, 2004 at 08:19:20PM +0200, [EMAIL PROTECTED] wrote: > Hello > > Why is it that PostgreSQL chooses to have features like replication, > fulltext indexing and GIS maintained by others outside of the sourcetree? I can tell you for sure that the replication systems are aimed at different ends, so having more than one of them is a strength. Also, you can use the replication systems to upgrade from one version of PostgreSQL to another (e.g. 7.1 to 7.2 or 7.3 to 8.0). Which source tree do you think the project should live in to accommodate that functionality? More generally, this question has been bandied about here several times over the past year. Have a look in the archives. A -- Andrew Sullivan | [EMAIL PROTECTED] The fact that technology doesn't work is no bar to success in the marketplace. --Philip Greenspun ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] The reasoning behind having several features outside of source?
On Monday 25 October 2004 14:19, [EMAIL PROTECTED] wrote: > Why is it that PostgreSQL chooses to have features like replication, > fulltext indexing and GIS maintained by others outside of the sourcetree? I'll make the attempt to answer best I can. PostgreSQL's architecture is very open and highly extensible. Several different solutions for these particular pieces have been independently developed, simply because the extensibility API is so flexible. Since they were originally developed outside the main source tree, many have tended to stay outside the main source tree and be maintained by their original developers. This is a result of the extensible design and a certain perlesque TMTOWTDI mindset. Since these features started out that way it is easier for the maintainers and developers of the main source tree to continue that relationship, since it keeps the main source tree cleaner and simpler for those who don't necessarily need the features in question. Further, the main tree's developers might not want to select one particular implementation (such as in replication) over another one, since they might meet different needs of different groups. In particular, there are several replication solutions available, each meeting a different set of needs. But the API used is robust and reliable, making these modules have the potential to be just as robust and reliable as the main source tree. This is a FAQ, but I'm not sure if it is addressed in any of our written FAQ lists. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] The reasoning behind having several features outside of source?
Hello 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. Thank you. Tim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
