Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA18800; Fri, 21 Aug 92 11:32:23 -0700
Message-Id: <9208211832.AA18800@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: Postgres for commercial use
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Mon, 17 Aug 92 08:38:56 PDT."
             <9208171538.AA26514@postgres.Berkeley.EDU> 
Date: Fri, 21 Aug 92 11:31:17 PDT

you write:

> I have some basic questions to ask about Postgres. They are the following:
> 1.  I understand postgres is not a standard RDBMS, but has several
>     extensions that make it more powerful. What are these extenstionsR ?.
>     I know that these are user-defined operators, User defined functions,
>     inhertitance etc. I was wondering from a relational point of view
>     how is it implemented (A syntax list of these extensions maybe ..)

I will send you the POSTGRES faq.  The basic idea is that each relation is
a class, and each tuple in it an instance of that class.  Classes inherit
attributes and methods (functions taking a class as an argument) in the
standard oo way (forgive my poor oo vocabulary).

A classic example:

	create person  (name = text, age = int2)
	create emp     (salary = int2) inherits (person)
	create student (gpa = float4)  inherits (person)
	create stud_emp(percent = float4) inherits (emp, student)

stud_emp has attributes (name, age, salary, gpa, percent) and any/all
methods defined on person, emp, and student.

> 2.  Is there support for stored procedures, database security etc ?

yes and no.  We provide language or POSTQUEL functions where we store
the text of the query, parsing and planning it on invocation.  This doesn't
result in any speed up (as stored procedures would), but we a planning
to store plans (instead of POSTQUEL text) in the future.  Database security
doesn't exist in the current release, but will be added in 4.1.

> 3.  We are OEMs and build newspaper software. Our customers are very
>     conservative. Our DB design problems are complex enough, to look at
>     a lateral solution. OODBMS is too new and the products not stabilised
>     - so I'd rather not get into that. So then my question, is Postgres
>     stable enough to be incorporated as a DB solution. Are there any
>     third party products such as report writer etc. that make Postgres a
>     viable commercial offering ? In fact, has anybody used postgres in
>     for their commercial product. If so, why did they choose it over
>     standard RDBMS packages ? 

Due primarily to lack of person power POSTGRES can't even come close to the
stability achieved in commercial products.  We do the best we can, but we
are at best 'buggy'.  Deciding to use University POSTGRES in a commercial
product can be a risky proposition.

POSTGRES comes with 'no frills': no report writer, no user interface (unless
you count the terminal monitor), and no real support.

> 3.  What plans exist to support SQL ? In the meantime, does a SQL parser
>     exists that converts to QUEL and passes to Postgres ?

We have no plans to do this.  It is hard to get DARPA to pay you to do
something that has been done by everyone else already.

> Thanks a million in advance

I'm not that expensive ;)


Jeff Meredith
mer@postgres.berkeley.edu