From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
Message-Id: <9407030949.AA23972@marie.physik.tu-berlin.de>
Subject: Re: postgres v4r2 for linux
To: corey@bbs.xnet.com (Corey Sweeney)
Cc: linux-postgres@native-ed.bc.ca
Date: Sun, 3 Jul 1994 11:50:27 +0200 (MET DST)
In-Reply-To: <9407030438.AA04e2p@bbs.xnet.com> from "Corey Sweeney" at Jul 2, 94 10:38:52 pm
Content-Type: text
Content-Length: 2632

> 
> Hey! it finnally happened.  Now we can get some real work done :)
> 
> Ok here's my proposal for the plan.  (it's the same plan as before, with a
> couple of additions of my own)
> 
> 
> ok, first we get it working with -Wall.  (without warnings)

That is a major project by itself, but a good thing to start with.


> 
> then we do that c++ification thing.  problably in several sub-steps.  I'm
> guessing that we won't actually want to use the c++ code untill we have the
> 2.6.0 compiler.  (due out soon).(2.5.8 is totally broken)

According to my experience, 2.5.8 is broken with respect to templates
and the other modern stuff, but quite ok for classes.


> Then we'll have a nifty database system, but we'll be lacking a nifty way to
> interfact to it.  So we should get onyx working with postgres.  (should be
> easy).  Onyx is a 4gl that was written with many c++ classes.  we don't care
> about the 4gl, but the classes are nifty because one of the layers in SQL. 
> Therefore allowing a developer to develop on postgres, and if he finds it too
> unstable, he can move to ingres (without code modification, just onyx
> configuration changes), then when it stabilizes out, move back to it.

I am in contact with Michael Kraehe, the developper of Onyx.  He has
started on working on an Onyx <--> Postgres link.  Maybe, he even
listens to this list.

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.


> Once were portable, then we can start working on a c++ class interface that is
> a backward compatible superset of the onyx classes, that are actually
> effecient, and have extended functionality (i.e. things not defined by SQL that
> are available in postgres should be added as extended classes)  (mainly varible
> length fields).

Other new things in postgres are Arrays, user defined types and
functions or rules.

> So, what do you think?  i really don't care about the onyx standard except for
> that it exsists already, and i don't know of any others.  So that why i
> recommend that one.

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

> Corey Sweeney
> corey@bbs.xnet.com


Kai