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

Marc,

> 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 :-)

Regards,

Thomas Hallgren