From: nitin@sybase.com (Nitin Borwankar)
Message-Id: <9407051808.AA21318@kaze.sybgate.sybase.com>
Subject: Re: postgres v4r2 for linux
To: wpp@marie.physik.tu-berlin.de (Kai Petzke)
Date: Tue, 5 Jul 94 11:08:29 PDT
Cc: corey@bbs.xnet.com, linux-postgres@native-ed.bc.ca
In-Reply-To: <9407030949.AA23972@marie.physik.tu-berlin.de>; from "Kai Petzke" at Jul 3, 94 11:50 am
content-length: 1809

In your message you, Kai Petzke, graciously said

> Onyx will eventually have an SQL -> Postquel translater.  The problem
> is, that this translater can't be better than Postquel.  Say: is
> postquel does not feature real aggregates or grouping, Onyx-SQL won't
> feature it either.
> 
> We will have to make the decision, whether to implement SQL native
> to postgres, or as an emulation.  That decision is not easy, as
> there are many aspects to consider.  For example, an emulated SQL
> will trigger all the Postquel rules defined on a given table, while
> an native SQL won't.

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.
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.

Why not instead build a SQL to *quel* translator for *University Ingres* ?
And then build a *SQL3* interface for postgres.
This will be the natural fit.

SQL 3 is the next revision of the SQL spec which is nearing completion.
It will have object-oriented features along with backward compatibility for
SQL2.
The spec for SQL3 is available via anonymous ftp from gatekeeper.dec.com.
I don't know the exact location but /pub/sql3 will probably work. 

Michael Stonebraker's new company ( formed to commercially develop
postgres technology ) is working on creating a SQL3 interface
to Montage ( the name for their commercial implementation )
 

[...]
> 
> I think, that we have already one interface (libpq), and should not
> concentrate too much on adding a second one.
> 

I agree wholeheartedly. 


> Kai
> 
>