Gevik Babakhani wrote:
I think the better question about all of this is:
What is the problem we are trying to solve?
Providing solutions that are looking for problems doesn't help us.
Sincerely,
Perhaps the current codebase and design in C will serve us for years and
years to come. In fact there is no doubt about that and switching to an OO
design is no easy task. But times change and technologies evolve. So should
any software solution that is hoping to continue and compete with other
competitors of the same kind.
Procedural programming languages like C may have been languages of choice
for many years but they gradually loose developer audience just because of
the reason above. I am afraid PG is no exception here.
A major problem I have with this suggestion is that PostgreSQL would
indeed be equivalent or better re-written in another language. All
PostgreSQL benchmarking and design decisions have been based upon
measuring the performance of PostgreSQL written in C for common
platforms. At it's most basic, if you were to do a strict 1:1
translation of PostgreSQL from C to Java, I feel confident in
guaranteeing that you will see a 10 times or more drop in performance.
Why? Because what is fast in Java is not the same as what is fast in C.
The design decisions would all need to be revisited, and the effect
would be exactly as already suggested - an immature design, competing
against other mature designs.
From C to C++ is only a smaller leap in the sense that pieces of
PostgreSQL could be migrated at a time. The result is still that an
OO-modelled PostgreSQL would be significantly different from a
procedure-modelled PostgreSQL, and you would always be facing the
compromise of: 1) Should re-write this part to be OO? or 2) Should we
leave it alone for now (and then, why bother using C++?).
Somebody working on a thesis or with thousands of hours of spare time
and no inclination to work on any other part, might prove that many of
the PostgreSQL technologies port well to another language - but it is
far more likely that the result will be a bust.
I'd rather core developer effort was spent doing what they are doing today.
Cheers,
mark
--
Mark Mielke <[EMAIL PROTECTED]>