Re: [HACKERS] Historical trivia (was Re: First Major Open Source Database)

sorry, i never hit "send" on this.

Andrew Yu <ayu@informix.com> writes:
>> From: Bruce Momjian <pgman@candle.pha.pa.us>
>> Subject: Re: [HACKERS] Historical trivia (was Re: First Major Open Source Database)
>> To: Tom Lane <tgl@sss.pgh.pa.us>
>> Date: Sat, 8 Jan 2000 01:31:40 -0500 (EST)
>> CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>, jolly@weblogic.com,
>>         ayu@informix.com
>> 
>> I am CC'ing Jolly and Andrew on this.  They may know the answer.
>> 
>> ---------------------------------------------------------------------------
>> 
>>> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>>>>> It did not use any Ingres code, as told to me by Jolly, I
>>>>> think.  My book has Ingres mentioned as an "ancestor" of
>>>>> Postgres.
>>> 
>>>> I suppose we could have figured this out ourselves, since
>>>> Postgres was originally written in Lisp, and afaik Ingres was
>>>> always C or somesuch traditional compiled-only code. We still
>>>> see evidence of this in our code tree with the way lists and
>>>> parser nodes are handled.
>>> 
>>> It's clear from both the comments and remnants of coding
>>> conventions that the planner/optimizer was originally Lisp code,
>>> and was hand- translated to C at some point in the dim mists of
>>> prehistory (early 1990s, possibly ;-)).  That Lisp heritage is
>>> responsible for some of the better things about the code, and
>>> also some of the worse things.
>>> 
>>> But I'm not sure I believe that *all* of the code was originally
>>> Lisp.  I've never heard of a Lisp interface for yacc-generated
>>> parsers, for example.  The parts of the executor I've looked at
>>> don't seem nearly as Lispy as the parser/planner/optimizer,
>>> either.  So it seems possible that parts of Postgres were
>>> written afresh in Lisp while other parts were lifted from an
>>> older C implementation.
>>> 
>>> </idle speculation>
>>> 
>>> Does anyone here still recall the origins of Postgres?  I'm
>>> curious to know more about the history of this beast.
> 
> I was under the impression that postgres was all lisp at one point
> and that it does not share code with Ingres. Unfortuantely, all this
> happen before my time. You must know about this for sure? I guess I
> can ask my boss (Zelaine Fong) too. :)

the project started with jeff anton, steven grady and some grad
students.  they started from scratch.  no code was inherited from
ingres.  (later, i ripped off a little bit of code from ingres to
implement one of the numeric types...i think i might have replaced it
with posix calls before pg95.)

from the beginning until late 1989, the system was divided into two
parts: one written in C, the other written in franz lisp.  the line
was drawn below the traffic cop, query executor and query optimizer;
hence, the flow of control went back and forth from the lisp "top"
half into the C "bottom" half.  the interface was relatively narrow
(parser, system catalogs, access method interface) and used the
essentially undocumented franz lisp equivalent of JNI.

steven wrote and maintained the parser, which was always written using
lex/yacc (i.e., C) but had to generate (in C!) a lisp parse tree.
jeff wrote the traffic cop and (the first version of) a lot of the
rest of the C software.  mike hirohama joined early on and wrote stuff
like the first b-tree implementation before becoming chief programmer
in 1988.  chinheng hong (an MS student, now at oracle) wrote the query
executor in franz lisp.  zelaine fong (an MS student, now at informix)
wrote the query optimizer in franz lisp.  lisp/C integration was still
going on when philip chang and i joined the project in late 1986.

in late 1989, jeff goh wrote a postgres-specific lisp->C translator
that automated most of the conversion.

i think the executor looks more C-like for a couple of reasons.
first, people have hacked on the (C version of the) executor a lot
more because it's a lot less mysterious and fragile than the
still-lispy-looking optimizer.  chinheng's executor was basically gone
by 1991.  second, the executor mostly just walks the query plan and
"does stuff," whereas the optimizer is actually creating nodes and
lists and manipulating those data structures.  furthermore, it has
many more such data structures than just the parse tree and query plan
data structures (i.e., the ones for its own internal use).  this means
that a larger fraction of the code has to do with getting/setting
these lispy structures.

hope this helps,
-- paul