Subject: Re: 3 Q's re: Ansification, Make, Alpha

From: [email-masked] (Greg Kemnitz)
Date: Mon, 18 Jan 93 16:48:17 -0800

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

---

From: [email-masked]
Date: Tue, 19 Jan 93 12:37:15 -0800

Please bear with the recapitulation of this thread; there seem to have
been some misunderstandings based on earlier messages.  I've used
ellipses (...) to condense earlier remarks.  To further reduce
confusion I've separated the ANSI discussion from the issues of Posix,
Make, GCC and whether Postgres is/should become freeware.

Robert Withrow:
	I desire to correspond with people who are involved in ...
	Ansification of the source.

Alan Glass:
	[ANSIfication] is on the agenda for the coming release.  We are
	trying to do this in a way that will allow compilation by non-ANSI
	compilers, and let us use the new ANSI features to best advantage.

Me:	Why ... allow compilation by non-ANSI compilers?  Doesn't this
	... reduce the benefit that ANSI C can provide?  What platforms
	do you consider important that do not yet support an ANSI compiler?

Greg Kemnitz:
	Postgres predates validated ANSI compilers on many platforms .... 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.

It is a misconception that ANSI C invalidates older C code.  The truth
is that ANSI C compilers accept older (often called Classic, or K&R) C
programs with few if any changes required.  This was a requirement of
the ANSI C standardization process.  Correct use of ANSI C *reduces*
portability problems *inherent* in Classic C code.

What ANSI C provides is a few new constructs, e.g. function
prototypes, and many tighter definitions of formerly gray areas, e.g.
whether * is needed to call a function by a pointer.  It allows, but
deprecates many unsafe practices, e.g. old-fashioned function
declarations.

ANSI C compilers will compile software as it is migrated from Classic
C to take best advantage of ANSI C features, regardless of how slow
and piecemeal that migration goes.  Also, tools exist, e.g. protoize,
that can automatically upgrade old software to take advantage of some
ANSI C features.

On the other hand, a Classic C compiler will not compile a mixture of
Classic and ANSI features.  With significant effort one can use macros
and conditional compilation code which allow the optional use of ANSI
C features.  This degrades program readability and reliability, hence
the overall quality of the code.  Why do this to Postgres?

_Greg

J. Greg Davidson	Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA
 
[email-masked]					ucsd----+--vis
[email-masked]		 			nosc----|

	*****************************************************
	*   Member of the League for Programming Freedom.   *
	*   For more info, write to [email-masked]  *
	*****************************************************