The reasoning behind having several features outside of source?

[nd02tsk]

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

[Joshua D. Drake]

nd*****@student.hig.se wrote:

Hello

Why is it that PostgreSQL chooses to have features like replication,
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.
fulltext indexing and GIS maintained by others outside of the sourcetree?
This I am unsure of although it may be licensing issues.

J

I appreciate any answers.

Thank you.

Tim


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
[phone] - [e-mail] - 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

[Marc G. Fournier]

On Mon, 25 Oct 2004 nd*****@student.hig.se wrote:

Hello

Why is it that PostgreSQL chooses to have features like replication,
fulltext indexing and GIS maintained by others outside of the sourcetree?

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: sc*****@hub.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

[Jan Wieck]

On 10/25/2004 2:19 PM, nd*****@student.hig.se wrote:

Hello

Why is it that PostgreSQL chooses to have features like replication,
fulltext indexing and GIS maintained by others outside of the sourcetree?

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. #
#================================================= = Ja******@Yahoo.com #

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

[Lamar Owen]

On Monday 25 October 2004 14:19, nd*****@student.hig.se 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
[phone]
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

[Andrew Sullivan]

On Mon, Oct 25, 2004 at 08:19:20PM +0200, nd*****@student.hig.se 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 | aj*@crankycanuck.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 ma*******@postgresql.org)

[Jeff Davis]

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, nd*****@student.hig.se 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 appreciate any answers.

Thank you.

Tim


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Jeff Davis <jd**********@empires.org>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Chris Browne]

nd*****@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.

[nd02tsk]

Jeff Davis wrote:

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.

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 ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Marc G. Fournier]

On Sat, 30 Oct 2004 nd*****@student.hig.se wrote:

Jeff Davis wrote:

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.

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?

Yes, which is why you will find that several of them are 'outside
projects' for development purposes ... in fact, if you looked back at the
earlier 7.x series, you will find that they had more interfaces then the
current code does ... alot has been moved out over the years. libpq++ is
a prime example of something that had official status for the longest
time, but where someone came along and wrote a 'better' version of it,
which is now on gborg ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

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

[Joshua D. Drake]

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?


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

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

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
[phone] - [e-mail] - 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 ma*******@postgresql.org)

[Marc G. Fournier]

On Sat, 30 Oct 2004, Joshua D. Drake 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?

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

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: sc*****@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Tom Lane]

"Marc G. Fournier" <sc*****@postgresql.org> writes:

On Sat, 30 Oct 2004 nd*****@student.hig.se 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?

Yes, which is why you will find that several of them are 'outside
projects' for development purposes ...

We have been trying to "push out" anything that is not fairly tightly
tied to the core backend, enough so that it's easier to maintain with
the backend than separately. The PL languages are in a gray area, but
for the most part it seems better to treat them as part of the core for
maintenance purposes. They tend to need fixed whenever we make any
changes to internal backend APIs. (See for instance discussion just now
in pghackers with Thomas Hallgren --- if PL/Java had been part of the
core distro then he'd not now be playing catchup to make it work with
8.0 CVS tip...)

regards, tom lane

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

[Alvaro Herrera]

On Sat, Oct 30, 2004 at 04:39:42PM -0300, Marc G. Fournier wrote:

On Sat, 30 Oct 2004, Joshua D. Drake wrote:

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

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

But both Slony-II and the CMD replication solution do ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No reniegues de lo que alguna vez creíste"
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Jan Wieck]

On 10/30/2004 3:39 PM, Marc G. Fournier wrote:

On Sat, 30 Oct 2004, Joshua D. Drake 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?

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

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

Slony-II will probably need some additional features. But I consider it
a sign for an immature design not to be able to define those features in
form of an API and instead starting to hack together a prototype inside
of the backend that later down the road will get promoted to a solution
because there never will be any time to turn the findings of that
explore-phase into a design and develop according to that.
Jan

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #

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