Skip site navigation (1) Skip section navigation (2)

Re: The reasoning behind having several features outside of source?

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: The reasoning behind having several features outside of source?
Date: 2004-10-29 19:43:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
nd02tsk(at)student(dot)hig(dot)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

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="" in String.concat "@" [name;tld];;
A VAX is virtually a computer, but not quite.

In response to

pgsql-general by date

Next:From: Chris BrowneDate: 2004-10-29 19:47:22
Subject: Re: Reasoning behind process instead of thread based
Previous:From: Sally RuggeroDate: 2004-10-29 19:42:10
Subject: Recommended Procedure for Archiving Table Data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group