> 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-sideextensions) were completely usable in C++. It's not so much hacking on the internals, it's more about being
tobuild an extension DLL in C++ that makes extensive use of calls to internals without having to write shim layers.
Thatlooks 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
infact.
> > 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
