> 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
> > use of inline functions instead of macros, don't particularly need
> > at all.
My point is only that C++ can be used to provide better type safety, with
little of any effect on performance.
David M Bennett FACS
Andl - A New Database Language - andl.org
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: