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