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