>Nick Bastin - RBB Systems, Inc.
>Out hme0, through the Cat5K, Across the ATM backbone, through the
>firewall, past the provider, hit the router, down the fiber, off another
>router... Nothing but net.
>Nick,
>
>That's not necessarily true.  While it is almost always true for
>consumer-off-the-shelf software, there is plenty of software that
>doesn't fit into that category.  Quite a few software companies will
>sign support contracts (IBM is one) where they will take responsibility
>for damage that may arise from the use of the software.  This is also
>the case for many industrial software packages.  Granted, PostgreSQL
>doesn't really fall into any of these categories, but these types of
>warratees *do* exist.
>
Nick, 
	I didn't say that those contracts don't exist. But
they are usually in conjunction with some specific application.
For example, Oracle's general license on there database
product's is written in such a way that they cannot be
held accountable for anything a customer may do with there
database. The reason's are simple, Oracle couldn't possibly
come up with all of the possible scenario's that their
general purpose software could fail in. 
	But, on the flip side, Oracle has an Iron clad warranty 
on the use of "Oracle Financials". And you can be assured
what a DBA can and cannot do are very strictly defined within
that contract. And if you violate that contract in any minor
way and "Oracle Financials" has any problem, the lawyer's
will use this as a way out.
	As for comparing commercial database software to PostgreSQL
reliability. I had to rebuild a Oracle 7.0 database engine
two weeks ago because it was corrupt. And last week I spent
two days exporting/importing a Oracle 7.3 two tablespaces 
because of some corruption of some type. And I did this
after Oracle's tech staff suggested it. 
	What does all of this mean. Well, Oracle (Commercial)
database packages have some of these same problems that plague
PostgreSQL. The only difference is they are less frequent and
are generally tied to the development cycle. I tend to think
of this as a evolution cycle and Postgres's cycle is on 
steroids.


My two cents.
D.



Mon, 8 Feb 1999 11:26:52 -0500 
Dan Gowin <DGowin@avantec.net>
RE: Commercial support, was Re: [HACKERS] v6.4.3 ?
Dan Gowin <DGowin@avantec.net> writes:
> 	What does all of this mean. Well, Oracle (Commercial)
> database packages have some of these same problems that plague
> PostgreSQL. The only difference is they are less frequent and
> are generally tied to the development cycle. I tend to think
> of this as a evolution cycle and Postgres's cycle is on 
> steroids.

That it is.

I think most people see rapid release cycles as part of the success
story for open-source software, so I'm not eager to try to slow down
the cycle.  But we do need to consider that many users of Postgres
will be more concerned about stability and reliability than having
the latest whizzy features.  Making a commitment to maintain the
prior major release as well as the current one seems like a good
answer.

I see a number of different specific issues that are getting lumped
together under the notion of "commercial support":

1. Personal attention to a particular installation, guaranteed
response to a problem, etc.  These are things that can and should
be handled by a distributed network of support consultants as Terry
was suggesting.

2. Bug fixing and feature additions in the supported product.  (This
is different from "support" in the sense of correcting an admin's
mistake, figuring out a workaround, or otherwise supporting a specific
installation.  I'm thinking about changes that require developer-grade
understanding of the code.)  I don't really think we need to do
anything differently here, other than have a higher level of effort on
back-patching prior releases.  Like most open-source projects we are
far *better* than commercial practice in this area.

3. Commercial guarantees/warrantees/indemnifications, ie, someone pays
you money if the thing doesn't work for you.  I don't think this is
going to happen, at least not for the core Postgres development.  Who
in their right mind would warrantee something they didn't have 100%
control over?  If there's really a demand for it then probably
companies will offer packages based on back-rev Postgres releases that
they have tested like mad and hired a few programmers specifically to
fix bugs in.  (They'd probably want to put it on a back-rev OS,
too...)

We should try to encourage qualified people to become support
consultants to deal with point #1.  I don't think this group can
or should do anything about #3 though --- that looks like a splinter
project to me.  I don't mind someone else taking it up, but it would
be a distraction from the core development project for us.

			regards, tom lane

Mon, 08 Feb 1999 11:56:49 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Commercial support, was Re: [HACKERS] v6.4.3 ? 