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

nd02tsk (AT) student (DOT) hig.se wrote:
Well this is because there are multiple versions of replication and each
has pros and cons. The community does not wish to endorse any of them.

This I am unsure of although it may be licensing issues.

J




--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd (AT) commandprompt (DOT) com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Mon, 25 Oct 2004 nd02tsk (AT) student (DOT) hig.se wrote:

well, in the case of replication, there are about a half dozen replication
solutions currently out there, each providing replication in a different
way, and non of them being "the definitive replication" ... also,
PostgreSQL was designed to be extensible, so stuff like FTI and GIS can be
plugged in *after* the server itself is up and running ... they are 'add
ons', not 'core features' ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy (AT) hub (DOT) org Yahoo!: yscrappy ICQ: 7615664

---------------------------(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

On 10/25/2004 2:19 PM, nd02tsk (AT) student (DOT) hig.se wrote:

Because those are very diverse features. Replication especially, which
is a bunch of different technical solutions for more than a dozen
problems. In these matters there is no one size that fits all, and
because of that they don't belong into the core distribution of the
database server.

For the next replication system I am planning, there need to be some
changes to the core server. But these will be reduced to hooks and APIs
that will be more general and open to discussion to provide the
infrastructure requited by the majority of replication extensions.


Jan

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = JanWieck (AT) Yahoo (DOT) com #

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Monday 25 October 2004 14:19, nd02tsk (AT) student (DOT) hig.se wrote:
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

On Mon, Oct 25, 2004 at 08:19:20PM +0200, nd02tsk (AT) student (DOT) hig.se wrote:
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 | ajs (AT) crankycanuck (DOT) ca
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 majordomo (AT) postgresql (DOT) org)

Other people have answered, but I'd like to add:

It makes it much faster to fix bugs and improve features in the projects
outside of the source tree. If replication has a bug, you don't want to
wait for the next point release, you want a fix *now*. PostgreSQL is a
big project, and can't make new point releases every time a bug appears
in a small subsystem.

To make an analogy, imagine if you had to wait for a new release of your
operating system to fix a bug in an SSL library?

Regards,
Jeff Davis

On Mon, 2004-10-25 at 20:19 +0200, nd02tsk (AT) student (DOT) hig.se wrote:
Jeff Davis <jdavis-pgsql (AT) empires (DOT) org>


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

nd02tsk (AT) student (DOT) hig.se writes:
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.

Jeff Davis wrote:

Replication is one subsystem not included in source tree. But PostgreSQL
has other subsystems that are included such as plugins for procedural
languages. So isn't the same risks involved with them?

Tim


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

No, not really. Because items such as plPerl don't require
changes to the backend. Replication requires changes to the backend.

Sincerely,

Joshua D. Drake



--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd (AT) commandprompt (DOT) com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)