Re: Unsupported 3rd-party solutions (Was: Few questions on postgresql (dblink, 2pc, clustering))

I think the major question would still remain, "What is that worth?",
if PostGreSQL says that the software works with their product. If there was a problem with it, or
if the developer decided not to upgrade to a new version with the main
product, there is still no warranty. PostGreSQL will probably not pick
up the development and upgrade it themselves.

This is very similar to asking the Linux distributions to officially support
PostGreSQL. They do to a level, but that includes just the
installation. If they upgrade and PostGreSQL in not compliant with
them anymore they will tell you they do not support it anymore. If you
think about it, PostGreSQL is a third-party product to the Operating
System. I don't think PostGreSQL is officially "REDHAT compliant" (as
an example). Then this supporting software is third-party to the DBMS. This
seems to be the way OpenSource works.

I agree with you that a third-party solution may not be the most
comfortable thing to do, but that is one of the inherent risks when
going Open Source. There is also no guarantee on PostGreSQL doing what
it is supposed to or what they say it does. The only difference
between using PostGreSQL and using a product that works with
PostGreSQL is that you have increased your risk. It was not like you
were in the safe-zone and were determining whether to take a risk or
not.

________________________________________________________________________________

On Sunday 22 August 2004 16:45, you wrote:
> Jim Worke wrote:
> > I don't mean to be rude or anything, but having 3rd-party solution is a
> > scary option for a business enterprise. I know that they're stable and
> > all, but if it's not supported by PostgreSQL themselves (i.e. included in
> > PostgreSQL as a whole package), we're afraid that we have to change our
> > code/design in case the product has stopped progress.
> >
> > For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync
> > with PostgreSQL's current version (I'm not blaming the guy... He's
> > created a very good solution and I'm thankful for that). It's just that
> > for my company (and I guess many other companies too), it's more
> > appealing to have a database solution that comes in a package.
>
> Those are very interesting remarks. I'm the author of PL/Java, a module
> that also could be thought of as "not supported by PostgreSQL
> themselves", and I've made the same reflection as you have. It would be
> beneficial to have some organisational entity within Postgres where this
> issue could be addressed (i.e. packaging/synchronization and supported
> configurations). I think it could give a real boost to PostgreSQL as such.
>
> Sure, an open source community does not make support commitments. But
> the PostgreSQL community is large and that creates (a sense of) safety
> and continuity. This sense is not automatically transferred to the
> "3rd-party solutions".
>
> From a users perspective and perhaps especially from the decision
> makers perspective, the fact that you have to download various modules
> from gborg etc. is indeed scary. Who will support your chosen solution a
> year from now? IMHO, if PosgreSQL is aiming for larger business
> acceptance, this has to be resolved. Contributors like myself must be
> given the opportunity to get things "verified" and checked in as
> "supported". It would do PostgreSQL an awful lot of good if there where
> supported configurations including replication, server side language
> support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things
> that you'd normally find in commercial enterprise solutions.

I'm CC'ing this to the postgresql mailing list.

I fully agree to your statement (to get things "verified" and checked in as
"supported"). Hopefully there's a way out for this...

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org