> 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.

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:

Reply via email to