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

Re: Unsupported 3rd-party solutions (Was: Few questions

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unsupported 3rd-party solutions (Was: Few questions
Date: 2004-08-22 17:52:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general

> Its actually worth alot less then you think ... for instance, if we 
> were to import Slony as part of 8.0 (we won't, but its an example) 
> since it is "todays fashion for replication", there is no guarantee 
> that for 8.1, we don't replace it with something that happens to be 
> better then ... then the person that deployed Slony because it was 
> 'the fashion of the day' is now using something that is no longer 
> considered "supported"?  Do they change then?
> libpq++ is a better example, because it happened ... nobody was 
> working on it, and someone came along and decided that since he felt 
> it was too broken, he started to develop his own which became better 
> then what we had in the tree, even though the one in the tree was 
> considered "the supported one" ...

I never said that the conglomerate of "supported" add-ons should be 
static. On the contrary! The entity behind what I'm proposing should 
strive to provide "best of breed" solutions. The fact that you actually 
replace a dying module with a superior vital one is not negative to 
anyone as long as you provide a migration path.

What do you think would happen if the libpq++ replacement was 
acknowledged and supported by PostgreSQL provided the people behind it 
made migration simple for existing libpq++ users (the question is 
hypothetical, I have no clue how easy or difficult such a migration is 
in real life)?

> The benefit (and drawback) to OSS is that it is possible to have 
> several potential solutions to the same problem ... in 6 months time, 
> who says there is no second (or third) implementation of PL/Java out 
> there?  Or pl/PHP?

PL/Java is a good example since it's one of two server side Java 
solutions. The other one is PL/J. While they provide the same 
functionality, they are fundamentally different in implementation and 
the best choice is likely to vary depending on the intended use (this is 
b.t.w. very true for different replication solutions also, so the 
remainder of this argument is not specific to server side java).

There's nothing wrong with this. PostgreSQL could support more than one 
solution and provide guidelines describing when one is a better solution 
then the other(s). Further more, PostgreSQL could put up some 
requirements to the contributors so that they where inclined to expose 
somewhat similar interfaces to the end user, thereby making it easy for 
the end user to try out more than one.

Should yet another solution pop up, well then the contributor of that 
one has to motivate why it too should be supported. Perhaps the 
motivation is that it's very similar to an existing solution but it 
shows superior performance and stability. When that happens (and is 
proven), the existing solution is replaced. The contributor of the new 
solution must of course ensure ease of migration.

A solution that is judged equal or not as good should be rejected on the 
base that a viable solution that perfoms same task is already supported. 
It's no different from accepting or rejecting patches really. It's just 
on a larger scale.

Some efforts could be made to encourage potential contributors of new 
modules to get involved with existing work instead of providing new 
solutions for already existing ones (such as with the libpg++). The 
advantage with OSS is that an offer to contribute is very often gladly 
accepted by the project owner :-)


Thomas Hallgren

In response to


pgsql-general by date

Next:From: Thomas HallgrenDate: 2004-08-22 18:00:34
Subject: Re: Unsupported 3rd-party solutions (Was: Few questions on postgresql
Previous:From: Tom LaneDate: 2004-08-22 17:37:29
Subject: Re: About inheritance

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