> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
