Subject: Re: postgres v4r2 for linux

From: [email-masked] (Kai Petzke)
Date: Sun, 3 Jul 1994 11:50:27 +0200 (MET DST)

> 
> 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
> [email-masked]

Kai

---

From: [email-masked] (Nitin Borwankar)
Date: Tue, 5 Jul 94 11:08:29 PDT

In your message you, Kai Petzke, graciously said

> will trigger all the Postquel rules defined on a given table, while

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 )

[...]
> concentrate too much on adding a second one.

I agree wholeheartedly.

---

From: [email-masked] (Kai Petzke)
Date: Tue, 5 Jul 1994 23:12:19 +0100 (MET DST)

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

> database as a relational ( table-based records ) database ie as a reduced

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.

> 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

---

From: [email-masked] (Kai Petzke)
Date: Sat, 9 Jul 1994 23:08:00 +0200 (MET DST)

> ok, first we get it working with -Wall.  (without warnings)

I think so, too.  I hope, that we can parallelize this task.
Everybody who wants to help catches a directory, and tries to
get all the files in it compiled without warnings.

I want to do the beginning: I choose ~postgres/src/backend/planner.

There are two problems, though:

a) Casts to a superclass.  C does no implicit casting from a
   subclass to a superclass, C++ does.  To turn of the C compiler
   warnings would require to add casts, which are bad for C++,
   though, because they inhibit type checking.

   I see the following alternatives:
   - ignore the C warnings about illegal pointers passed to functions.
   - add the casts, as a macro call.  Eg:
     #ifdef  __cplusplus
     #define super(x) (x)		/* C - Version */
     #define super(x) 			/* C++ - Version */
     #endif

     foo(super(Node) arg1, arg2);

     That would call the function foo() with arg1 converted to type
     Node (the base type of the Postgres), and arg2 unmodified.

b) Communication.  Does anybody know of a method to keep several
   world wide distributed versions of an RCS log identical?

   I guess, not, so we will have to go for something less
   sophisticated.  I can volunteer to collect patches.  E-mail is
   quite reliable here, despite the ftp problems.  The bad thing
   is for modifications to header files, because they affect
   everybody's work.  Maybe patches to headers should be posted
   to the list immediately.

Kai