Thread: 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
nd02tsk@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. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
On Mon, 25 Oct 2004 nd02tsk@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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On 10/25/2004 2:19 PM, nd02tsk@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. # #================================================== JanWieck@Yahoo.com #
On Monday 25 October 2004 14:19, nd02tsk@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 (828)862-5554 www.pari.edu
On Mon, Oct 25, 2004 at 08:19:20PM +0200, nd02tsk@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 | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
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@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 <jdavis-pgsql@empires.org>
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.
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
On Sat, 30 Oct 2004 nd02tsk@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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
>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 majordomo@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. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Sat, 30 Oct 2004 nd02tsk@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
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"
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. # #================================================== JanWieck@Yahoo.com #