Re: [GENERAL] C++ port of Postgres

> Well, getting so that we can at least compile in both systems would
> certainly increase the chances of somebody being willing to work on
> such a design.

From my particular perspective it would be enough if all the internal headers (that one needs to use in writing server-side extensions) were completely usable in C++. It's not so much hacking on the internals, it's more about being to build an extension DLL in C++ that makes extensive use of calls to internals without having to write shim layers. That looks like a lot less work than a full C++ port.

And if nobody ever does, then at least people who want
> to fork and do research projects based on PostgreSQL will have
> slightly less work to do when they want to hack it up. PostgreSQL
> seems to be a very popular starting point for research work, but a
> paper I read recently complained about the antiquity of our code base.
> I prefer to call that backward-compatibility, but at some point people
> stop thinking of you as backward-compatible and instead think of you
> as simply backward.

Certainly the positive arguments for sticking with pure C are diminishing over time, perhaps faster in perception than in fact.

> > A lot of the other things people have muttered about, such as
> heavier
> > use of inline functions instead of macros, don't particularly need
> C++
> > at all.

My point is only that C++ can be used to provide better type safety, with little of any effect on performance.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org