From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
Message-Id: <9407052112.AA12828@marie.physik.tu-berlin.de>
Subject: Re: postgres v4r2 for linux
To: nitin@sybase.com (Nitin Borwankar)
Date: Tue, 5 Jul 1994 23:12:19 +0100 (MET DST)
Cc: corey@bbs.xnet.com, linux-postgres@native-ed.bc.ca
In-Reply-To: <9407051808.AA21318@kaze.sybgate.sybase.com> from "Nitin Borwankar" at Jul 5, 94 11:08:29 am
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 3303      

> I used to work for Ingres and now work for Sybase.
> A couple of points worth mentioning.
> SQL is a language for accessing table-based data whereas postquel
> has facilities to access objects also.
> Postquel is potentially more powerful than SQL.

There are two different versions of postquel:

a) The definition, as done by Stonebraker.
b) The implementation, as done by a team of programmers.

b) is only a subset of a).  While a) could emulate SQL, b) can't,
because it chokes out on every "group by" clause, and even half
of the "normal" aggregates.

People love SQL.  Their first question is: Is there a good freeware
database?  If you answer, that there are Ingres and Postgres and
OBST and Metalbase and Diamondbase, the next question will be: "And
which can do SQL?"  Sorry, they all can't :-(

How to get SQL into Postgres.  There are two answers I can think of:

I)  Write a new parser and planner module for postgres, which
    executes SQL queries.
II) Write an SQL -> Quel (or PostQuel) translater, and complete
    the implementation of PostQuel.

Method I) is what I mean, then I speak about making SQL native to
Postgres.  It will then have two parsers, and for every query, you
could decide which one to use.

The advantage would be, that these two query languages would not
get into each other's ways.  It should also be faster.

Method II) is the emulation approach.  It is very easy for simple
statements (select foo from bar where candy = "sugar") but gets
really complex for complicated queries (select a.x, min(b.y), c.z
from a, b, outer c where a.f1 = b.f1 and a.f2 = c.f2 group by a.x,
c.z).  SQL and QUEL have a different point of view about aggregates,
so does have Postquel plus the addition, that most aggregates are
not supported.

The more I think about it, I think the idea thrilling to try the
approach I): make SQL native.  We would issue a simple Postquel
query (retrieve (e.name) from e in emp where e.salary >= 500),
and take a look at how the planner treats it.

Then we would tell the SQL planner to treat it the same way.  We
would start with the basics -- simple queries, not with those things,
that were too complicated and/or time consuming for the Postgres
Team at Berkeley.

> Thus a SQL to postquel translator will allow you to use the object-oriented
> database as a relational ( table-based records ) database ie as a reduced
> functionality subset.

Yes.  Decreased functionality, but increased usability for the
beginner: an "SQL for dummies" book is available everywhere, but I
have not yet seen "postgres for dummies".  

> Why not instead build a SQL to *quel* translator for *University Ingres* ?

It is already in the works by Michael Kraehe.

> And then build a *SQL3* interface for postgres.
> This will be the natural fit.

Agreed.  Postgres has a few advantages over Ingres.  It is faster, it
has finer locking, the code is newer, it has transactions.  So SQL2
for Postgres is an reasonable step in my opionion.  If that has been
done, SQL3 will be another reasonable step.

Jimbo has said on this list, that they were sometimes forced to
learn to fly, before they could walk (or something like this).  I
think, he is right, and I want to avoid repeating that error.  I
even get more and more doubts about my C -> C++ plans.


[...]


Kai