Re: RustgreSQL

On Sun, Jan 8, 2017 at 4:59 AM, Gavin Flower
<GavinFlower(at)archidevsys(dot)co(dot)nz> wrote:
>> Is this completely unrealistic or is it carved in stone PostgreSQL will
>> always be a C project forever and ever?
>>
> From my very limited understanding, PostgreSQL is more likely to be
> converted to C++!

I'm tempted to snarkily reply that we should start by finishing the
conversion of PostgreSQL from LISP to C before we worry about
converting it to anything else. There are various code comments that
imply that it actually was LISP at one time and I can certainly
believe that given our incredibly wasteful use of linked lists in so
many places. gram.y asserts that this problem was fixed as far as the
grammar is concerned...

* AUTHOR DATE MAJOR EVENT
* Andrew Yu Sept, 1994
POSTQUEL to SQL conversion
* Andrew Yu Oct, 1994 lispy
code conversion

...but I think it'd be fair to say that even there it was fixed only in part.

Anyway, with regards to either Rust (which I know very little about)
or C++ (which I know more about) I think it would be more promising to
think about enabling extensions to be written in such languages than
to think about converting the entire source base. A system like
PostgreSQL is almost a language of its own; we don't really code for
PostgreSQL in C, but in "PG-C". Learning the PG-specific idioms is
arguably more work than learning C itself, and that would still be
true, I think, if we had a "PG-C++" or a "PG-Rust" or a "PG-D"
variant. Still, if having such variants drew more programmers to work
on extending PostgreSQL, I think that would be worth some work on our
part to enable it. However, maintaining multiple copies of our
1.2-million-line source base just for easier reference by people more
familiar with one of those languages than with C sounds to me like it
would create more problems than it would solve.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company