Re: Mostly Harmless: Welcoming our C++ friends

Hi Peter,

> Have you considered writing a procedural language plugin for C++?

C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.

This series of patches is meant to address some of the
mechanics of getting C++ code compiled and linked for the
PostgreSQL backend environment.

At present the build system has no support for languages other
than C. To interface PostgreSQL to a C++ tool or library, it's
necessary to either hack the PostgreSQL build system, or bypass
it and set up your own build system. Either alternative is
likely to be non-portable and difficult for others to understand
or use. This presents a serious obstacle to contributing the
code to the PostgreSQL community or sharing it with others.

Because C++ is so similar to C, the PostgreSQL build system can
easily provide equal support to both languages. C++ users can
then integrate their code easily and portably, and others can
share the code with no need to wrestle with jury-rigged
makefiles. Nobody should have to figure out autoconf, m4,
and gmake unless they want to.

The 'c++configure' patch therefore addresses the necessity to
find the host platform's C++ compiler; invoke it with appropriate
options; link with the C++ runtime library; and initialize the
C++ environment.

Another obstacle which would not be addressed by a procedural
language plugin is the problem of access to the backend's APIs
and data structures. C++ can use C declarations directly with
no extra wrappers or translation layers such as other languages
usually need. However, C++ cannot parse a C header file in
which a C++ reserved word is used as an identifier. The
'c++reserved' patch renames some fields in a very few header
files so C++ code can interface with the PostgreSQL backend
environment to the extent needed for implementing a procedural
language, data type, etc. Although tedious, such renaming is
by far the most reliable, maintainable and efficient means of
exposing the PostgreSQL runtime facilities to C++. As a
straightforward renaming, it is a safe change: its completeness
and much of its correctness are checked by the C compiler.

> PostgreSQL supports a lot of extension languages, and none of
> them require the amount of backend changes that you outline here,
> because the PL plugin serves as glue.

C++ doesn't need glue like those other languages, but it does need
just a little help so that it can be used for the same kinds of
jobs that C is used for.

Those other extension languages, such as plpgsql or plpython,
serve a different audience than C or C++. They offer quick
development, ease of use, and high-level expressiveness where
performance is not the primary concern.

C or C++ are chosen when high performance is needed with precise
control over data representation and the ability to interoperate
directly with almost any language / library / system call / network
protocol / etc - notably, PostgreSQL's own tree structures and
data types.

Thanks for your comments; I hope I've responded adequately.
In any case, I welcome further dialogue on these or other topics.

Regards,
... kurt

Peter Eisentraut wrote:
> Kurt Harriman wrote:
>> Sometimes people would like to call C++ code in the PostgreSQL
>> backend environment... for example, in user-defined functions,
>> triggers, access methods. And there is sometimes a need for
>> C++ code to call back into PostgreSQL's C functions, such as
>> the SPI interface.
>
> Have you considered writing a procedural language plugin for C++?
> PostgreSQL supports a lot of extension languages, and none of them
> require the amount of backend changes that you outline here, because the
> PL plugin serves as glue.
>
>
>