Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA17906; Mon, 18 Jan 93 16:48:17 -0800
Date: Mon, 18 Jan 93 16:48:17 -0800
Message-Id: <9301190048.AA17906@postgres.Berkeley.EDU>
From: gregk@hadar.fai.com (Greg Kemnitz)
Subject: Re: 3 Q's re: Ansification, Make, Alpha
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu


I can't comment officially, but as the person in charge of Postgres at the
time many of these decisions were made (I was the chief programmer from 
August 1989 to December 1991), I feel that I should comment:

On GCC:

Various attempts were made to compile Postgres with GCC in the past, and they
all met with problems.  Since PCC (the "factory" compiler) typically worked,
we punted on GCC.  

We wanted the Postgres distribution to build from end-to-end on a completely
closed, factory installation of the operating system.  Also, we wanted to avoid
Unix guru status as a precondition to installation of Postgres.  While GNU
tools are much easier to install nowadays, this wasn't always the case.

Finally, the last thing we wanted was to have to support GNU tools and their
bugs in addition to our already complex and sometimes buggy software.  If there
was a bug in a compiler or something, we wanted it to be a vendor's bug so we
could easily test for it and find a workaround, and not have to worry about
wierd interactions involving a user's installation of GCC, bison, etc, and
Postgres.  We had enough of those types of bugs as it was.

On ANSI:

Postgres predates validated ANSI compilers on many platforms by a number of
years, and there is lots of code there.  Being K & R compliant maintained
the highest degree of portability.  If we had everything to do over, starting
in 1993, Postgres would almost certainly be implemented using C++ or at least
ANSI C, but a quarter of a million lines of code is a big incentive to avoid
talk of wholesale language changes.

On make:

Similar remarks as GCC.

On general philosophy:

Postgres was never intended to be a freeware replacement for commercial
DBMS's - rather its distribution in the public domain was intended to provide
it as a teaching and research tool, and to receive comments from users as to
the utility of the many data management advances implemented in the Postgres
software.

	Greg Kemnitz
	MultiSys, Inc
	kemnitz@netcom.com