Re: Mostly Harmless: c++bookends - patch 2 of 4

Hi,

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. Many useful software packages and
libraries are written in C++.

The attached series of 4 patches is meant to provide a minimal
level of support for C++ aficionados to easily compile and link
with the PostgreSQL backend. No new interfaces or wrappers are
provided. The goal is merely to make the backend a friendlier
place for developing extensions involving C++, with minimal
impact on the existing C code.

The proposed change is divided into 4 patches with the hope
that each will be simple and easy to review. They can be
reviewed and discussed independently, and I hope some or
all may be judged benign enough to be taken up into 8.5 or
earlier.

The patches are described in more detail below. They are:

1. c++reserved -- changes a few field and parameter
names which happened to be C++ reserved words

2. c++bookends -- adds C linkage declarations to a
few header files

3. c++configure -- adds C++ support to 'configure',
'make', and 'pg_config'. A new configure option
--enable-cplusplus links the C++ runtime library
in to the postgres backend.

4. c++exception -- converts unhandled C++ exceptions to
PostgreSQL elog(FATAL) errors

Regards,
... kurt

These patches are based on CVS head in which the latest commit was
user: petere
date: Thu Dec 04 17:51:28 2008 +0000
summary: Default values for function arguments

1. c++reserved

User-defined functions and extensions may need to access
backend data structures such as parse trees. A few of the
relevant header files contain field or parameter names
which happen to be C++ reserved words. This makes them
unusable from C++ because the compiler chokes on the
reserved word. It has been suggested that the C++ user
could surround these #includes with #defines to substitute
innocuous words for the reserved words; but that would be
unbearably kludgy, error prone and unmaintainable. A polite
host does not demand such things of a guest.

Fortunately, there are not many instances which are likely
to be encountered by our C++ guests, and these can easily
be changed. In memnodes.h, parsenodes.h, and primnodes.h,
this patch changes the following field names:

typename => typeName
typeid => typeOid
using => usingClause
delete => delete_context

Also, the patch changes a few parameter names in function
prototypes in makefuncs.h, parse_type.h, and builtins.h:

typename => typeName
typeid => typeOid
namespace => qualifier

There's no need to ask PostgreSQL developers to remember to
avoid C++ reserved words, because C++ users who are affected
by such occurrences can be asked to submit a corrective patch.

2. c++bookends

C++ code can call C functions and share global variables with C,
provided those declarations are surrounded by "bookends":

extern "C" {
...
};

Header files can be made bilingual, to declare interfaces which
look the same to both C and C++ callers. This is done by
placing C++ bookends within the header file, guarded by #ifdefs

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}; /* extern "C" */
#endif

This way the C++ caller can just #include the header file without
worrying whether the interface is implemented in C or C++.

Usually, extension modules written in C++ will put bookends around
all of their PostgreSQL #includes.

However, "postgres.h" usually stands alone as the first #include,
followed by some system #includes, and then the rest of the
PostgreSQL #includes. It is much nicer if a C++ file has just one
pair of bookends around its main block of PostgreSQL #includes.
This patch gives postgres.h its own internal bookends, making it
bilingual, so that its #include can continue to stand alone at the
head of each file.

Just a few additional header files are mentioned in the PostgreSQL
Reference Manual for add-on developers to use: fmgr.h, funcapi.h,
and spi.h. This patch adds bookends within those three files for
the benefit of beginners writing very simple extensions in C++.
Documentation and learning are simplified because C example code
can be compiled as C or C++ without change.

3. c++configure

This patch adds C++ support to the PostgreSQL build system.

After you have applied the patch, cd to the top of the source
tree (to the directory containing the file 'configure.in') and
execute these two commands to regenerate the 'configure' script
and some related files:
autoconf
autoheader

Much as it already does for the C compiler, the 'configure' script
will try to find the C++ compiler and set up appropriate command
line options. If 'configure' finds a C++ compiler, it will set up
src/Makefile.global to define the following makefile variables:

CXX = command for invoking C++ compiler
CXXCPP = command for invoking C++ preprocessor
CXXFLAGS = C++ compiler options
GXX = 'yes' if the C++ compiler is gcc/g++

Implicit rules are defined so that gmake will automatically invoke
the C++ compiler using the above variables given a source file name
suffixed with '.cpp' or '.cc'. So, to add a file named marvin.cpp
to the build, just add 'marvin.o' to the OBJS list in the Makefile.

To C++-compile a file with '.c' suffix, the Makefile should list
the .o file in both OBJS and CXXOBJS.

The pg_config utility can be used to display the CXX and CXXFLAGS.

Most C++ code typically uses some C++ features whose implementation
makes use of the compiler's runtime library: exceptions, static
constructors, new/delete, STL containers, stream I/O, etc. Specify
the following 'configure' option to link the C++ runtime library
into the postgres backend:

--enable-cplusplus

If --enable-cplusplus is specified, the makefile variable
'enable_cplusplus' will be set to 'yes', and pg_config.h will
#define ENABLE_CPLUSPLUS.

To ensure that the C++ runtime library is properly initialized,
on some platforms it is necessary for the main() function to be
compiled as C++. Therefore, if --enable-cplusplus is configured,
src/backend/main/main.c will be compiled as C++. This is
handled by the following lines in src/backend/main/Makefile:

ifeq ($(enable_cplusplus),yes)
CXXOBJS = main.o
endif

Fortunately, main.c can be compiled as either C or C++ with no
difficulty after applying the c++reserved and c++bookends
patches. To make main.c bilingual, all that was needed was
a pair of bookends around its #includes.

Limitations:

- I haven't added support for profiling and code coverage for
C++. Automatic dependency generation is supported, however.

- This ought to work on platforms which use GCC, and maybe some
others. The only one I have tested is x86_32 Linux with GCC
4.1.2. Hopefully some interested hackers will try it on
platforms to which they have access, and post the results.

4. c++exception

When C code calls C++ code, all C++ exceptions need to be caught
and fully contained within the C++ code. Exceptions should never
be thrown outward across the C/C++ frontier.

If an exception is not caught within C++ code, and the search for
a matching 'catch' bumps into a C stack frame, the result may be
platform dependent. On my platform (Linux/GCC), if this happens
in the postgres backend, the process terminates silently as if
abort() had been called.

With this patch, if --enable-cplusplus is configured,
PostgresMain defines a handler to intercept any uncaught C++
exception and convert it to a conventional PostgreSQL error of
FATAL severity. This allows the backend to clean up and report
the error before terminating.

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.

A seriously substantial portion of the diff for this patch all is
supporting trivial renaming, like changing everything that uses:

- TypeName *typename = (TypeName *) cmd->def;
+ TypeName *typeName = (TypeName *) cmd->def;

Is that really necessary? After going through a few pages of diff code
where supporting this trivial bit was the only change, my eyes glazed
over. Minimizing diff size makes it much more likely somebody will
complete a review of the functional parts of your submission before
getting bored.

If it is needed, I'd suggest you'd get a warmer reception here submitting
two diffs, one that just did the renaming and a second that actually had
the functional bits in it. Then it would be possible to casually scan the
renaming one for a second to see it was trivial and boring, followed by a
review of the functional one that was focused on its real changes.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Hi Greg,

Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
I'll try resubmitting them separately. The first diff consists
of just the renaming, which is intentionally trivial and boring.
The second diff adds a few extern "C" {...} declarations - also
trivial and boring, but small. The interesting part is in the
third diff.

Regards,
... kurt

Greg Smith wrote:
> A seriously substantial portion of the diff for this patch all is
> supporting trivial renaming, like changing everything that uses:
>
> - TypeName *typename = (TypeName *) cmd->def;
> + TypeName *typeName = (TypeName *) cmd->def;
>
> Is that really necessary? After going through a few pages of diff code
> where supporting this trivial bit was the only change, my eyes glazed
> over. Minimizing diff size makes it much more likely somebody will
> complete a review of the functional parts of your submission before
> getting bored.
>
> If it is needed, I'd suggest you'd get a warmer reception here
> submitting two diffs, one that just did the renaming and a second that
> actually had the functional bits in it. Then it would be possible to
> casually scan the renaming one for a second to see it was trivial and
> boring, followed by a review of the functional one that was focused on
> its real changes.
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
>
>

On Fri, 5 Dec 2008, Greg Smith wrote:

> If it is needed, I'd suggest you'd get a warmer reception here submitting two
> diffs, one that just did the renaming and a second that actually had the
> functional bits in it.

You can just ignore this late night bit of idiocy, or mock me for it as
you see fit. Note to other reviewers: if your e-mail client is the sort
that bunches a series of text attachments all together, make sure to
scroll completely past the first patch in the diff before you pay
attention to the rest of it. I'm going to bed.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

(Re-sending just the first of four patches: c++reserved)

These patches are based on CVS head in which the latest commit was
user: petere
date: Thu Dec 04 17:51:28 2008 +0000
summary: Default values for function arguments

1. c++reserved

User-defined functions and extensions may need to access
backend data structures such as parse trees. A few of the
relevant header files contain field or parameter names
which happen to be C++ reserved words. This makes them
unusable from C++ because the compiler chokes on the
reserved word. It has been suggested that the C++ user
could surround these #includes with #defines to substitute
innocuous words for the reserved words; but that would be
unbearably kludgy, error prone and unmaintainable. A polite
host does not demand such things of a guest.

Fortunately, there are not many instances which are likely
to be encountered by our C++ guests, and these can easily
be changed. In memnodes.h, parsenodes.h, and primnodes.h,
this patch changes the following field names:

typename => typeName
typeid => typeOid
using => usingClause
delete => delete_context

Also, the patch changes a few parameter names in function
prototypes in makefuncs.h, parse_type.h, and builtins.h:

typename => typeName
typeid => typeOid
namespace => qualifier

There's no need to ask PostgreSQL developers to remember to
avoid C++ reserved words, because C++ users who are affected
by such occurrences can be asked to submit a corrective patch.

(Re-sending just the second of four patches: c++bookends)

These patches are based on CVS head in which the latest commit was
user: petere
date: Thu Dec 04 17:51:28 2008 +0000
summary: Default values for function arguments

2. c++bookends

C++ code can call C functions and share global variables with C,
provided those declarations are surrounded by "bookends":

extern "C" {
...
};

Header files can be made bilingual, to declare interfaces which
look the same to both C and C++ callers. This is done by
placing C++ bookends within the header file, guarded by #ifdefs

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}; /* extern "C" */
#endif

This way the C++ caller can just #include the header file without
worrying whether the interface is implemented in C or C++.

Usually, extension modules written in C++ will put bookends around
all of their PostgreSQL #includes.

However, "postgres.h" usually stands alone as the first #include,
followed by some system #includes, and then the rest of the
PostgreSQL #includes. It is much nicer if a C++ file has just one
pair of bookends around its main block of PostgreSQL #includes.
This patch gives postgres.h its own internal bookends, making it
bilingual, so that its #include can continue to stand alone at the
head of each file.

Just a few additional header files are mentioned in the PostgreSQL
Reference Manual for add-on developers to use: fmgr.h, funcapi.h,
and spi.h. This patch adds bookends within those three files for
the benefit of beginners writing very simple extensions in C++.
Documentation and learning are simplified because C example code
can be compiled as C or C++ without change.

(Re-sending just the third of four patches: c++configure)

These patches are based on CVS head in which the latest commit was
user: petere
date: Thu Dec 04 17:51:28 2008 +0000
summary: Default values for function arguments

3. c++configure

This patch adds C++ support to the PostgreSQL build system.

After you have applied the patch, cd to the top of the source
tree (to the directory containing the file 'configure.in') and
execute these two commands to regenerate the 'configure' script
and some related files:
autoconf
autoheader

Much as it already does for the C compiler, the 'configure' script
will try to find the C++ compiler and set up appropriate command
line options. If 'configure' finds a C++ compiler, it will set up
src/Makefile.global to define the following makefile variables:

CXX = command for invoking C++ compiler
CXXCPP = command for invoking C++ preprocessor
CXXFLAGS = C++ compiler options
GXX = 'yes' if the C++ compiler is gcc/g++

Implicit rules are defined so that gmake will automatically invoke
the C++ compiler using the above variables given a source file name
suffixed with '.cpp' or '.cc'. So, to add a file named marvin.cpp
to the build, just add 'marvin.o' to the OBJS list in the Makefile.

To C++-compile a file with '.c' suffix, the Makefile should list
the .o file in both OBJS and CXXOBJS.

The pg_config utility can be used to display the CXX and CXXFLAGS.

Most C++ code typically uses some C++ features whose implementation
makes use of the compiler's runtime library: exceptions, static
constructors, new/delete, STL containers, stream I/O, etc. Specify
the following 'configure' option to link the C++ runtime library
into the postgres backend:

--enable-cplusplus

If --enable-cplusplus is specified, the makefile variable
'enable_cplusplus' will be set to 'yes', and pg_config.h will
#define ENABLE_CPLUSPLUS.

To ensure that the C++ runtime library is properly initialized,
on some platforms it is necessary for the main() function to be
compiled as C++. Therefore, if --enable-cplusplus is configured,
src/backend/main/main.c will be compiled as C++. This is
handled by the following lines in src/backend/main/Makefile:

ifeq ($(enable_cplusplus),yes)
CXXOBJS = main.o
endif

Fortunately, main.c can be compiled as either C or C++ with no
difficulty after applying the c++reserved and c++bookends
patches. To make main.c bilingual, all that was needed was
a pair of bookends around its #includes.

Limitations:

- I haven't added support for profiling and code coverage for
C++. Automatic dependency generation is supported, however.

- This ought to work on platforms which use GCC, and maybe some
others. The only one I have tested is x86_32 Linux with GCC
4.1.2. Hopefully some interested hackers will try it on
platforms to which they have access, and post the results.

(Re-sending just the fourth of four patches: c++exception)

These patches are based on CVS head in which the latest commit was
user: petere
date: Thu Dec 04 17:51:28 2008 +0000
summary: Default values for function arguments

4. c++exception

When C code calls C++ code, all C++ exceptions need to be caught
and fully contained within the C++ code. Exceptions should never
be thrown outward across the C/C++ frontier.

If an exception is not caught within C++ code, and the search for
a matching 'catch' bumps into a C stack frame, the result may be
platform dependent. On my platform (Linux/GCC), if this happens
in the postgres backend, the process terminates silently as if
abort() had been called.

With this patch, if --enable-cplusplus is configured,
PostgresMain defines a handler to intercept any uncaught C++
exception and convert it to a conventional PostgreSQL error of
FATAL severity. This allows the backend to clean up and report
the error before terminating.

On Fri, 5 Dec 2008, Kurt Harriman wrote:

> Actually I did email this to the list with 4 separate diffs in
> 4 separate attached files. I don't know why it appears all
> massed together at http://archives.postgresql.org/pgsql-hackers.

Thanks for being so attentive. Your e-mail was fine, the archives just
mash multiple text-based attachments tagged as Text/PLAIN together like
that, as does my mail reader. 1522 lines of only renaming in part 1, no
wonder I gave up.

I see you've already started re-sending the individual parts as separate
messages; that's nice for initial casual browsing of them, but will get
boring for everybody if you do that every time. If you've got more than
one text file to attach, for future updates you might consider a tar
archive of them to keep them running together in the archives. Once
you're putting stuff into an archive, might as well compress it too,
particularly for a patch of this size.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On Friday 05 December 2008 03:55, 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.

I think this patch is great, although I haven't had time to test it yet. The
only real "backend change" is the exception-handling clause; and the fact
that the backend will also be linked against the C++ runtime library.
Everything else is routine stuff that an experienced C++ developer would end
up catching while trying to get his build-system for a new project running;
but it could certainly scare away someone with less experience. Better to
deal with this way ahead of time and test it on a few platforms.

--
David Lee Lambert ... Software Developer
Cell phone: +1 586-873-8813 ; alt. email <dlambert(at)bmtcarhaul(dot)com> or
<lamber45(at)msu(dot)edu>
GPG key at http://www.lmert.com/keyring.txt

Greg Smith <gsmith(at)gregsmith(dot)com> writes:

> You can just ignore this late night bit of idiocy, or mock me for it as you see
> fit. Note to other reviewers: if your e-mail client is the sort that bunches
> a series of text attachments all together, make sure to scroll completely past
> the first patch in the diff before you pay attention to the rest of it. I'm
> going to bed.

Your email client is doing the right thing. The attachments had the following
header on them which controls this:

Content-Disposition: inline;

I wonder how many email clients let the poster control this header though :(
If you post with content-disposition set to "attachment" instead of "inline"
it should appear as a separate file you can save.

Regarding the patches, we could apply the trivial stuff right around the time
of the pgindent run, after all the major patches are drained from the queue so
it doesn't cause extra conflicts. It would still cause any other pending
patches for 8.5 to bitrot but from the sounds of things shouldn't be too hard
to fix up.

It seems to me we ought to do this regardless of whether we apply the
functional changes.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

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

Kurt Harriman <harriman(at)acm(dot)org> writes:

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

Well one thing that might be useful for a c++ procedural language would be
catching C++ exceptions and translating them into ereports which could then be
caught in Postgres.

That's actually what I thought you had done but I just reread your mail and
realized you only handled unhandled exceptions which cause the backend to die.

The other way around could be useful too -- catching ereports/elogs within a
backend API call from C++ code and throwing a C++ exception. I'm not sure if
that's doable though.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

Kurt Harriman wrote:
> > 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++.

FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.

Kurt Harriman <harriman(at)acm(dot)org> writes:
> [ make the backend C++-compilable ]

This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.

regards, tom lane

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Well one thing that might be useful for a c++ procedural language would be
> catching C++ exceptions and translating them into ereports which could then be
> caught in Postgres.

> That's actually what I thought you had done but I just reread your mail and
> realized you only handled unhandled exceptions which cause the backend to die.

Well, that's too bad, because fixing the error-handling impedance
mismatch is the one thing that's been missing from every previous
proposal, and it's the one thing that might actually make C++ in the
backend useful rather than a toy.

It's possible/likely that this would be easier to do in the context of
a PL; that would at least provide a single point at which to catch
C++ exceptions and turn them into elogs. The hard part is turning
elogs into exceptions so that errors thrown by core backend functions
that're called by the C++ code will behave as a C++ programmer would
expect.

For comparison look at the way that errors are handled in pl/perl etc.
The relatively narrow "SPI" API for calling back into the main backend
makes it somewhat sane to convert elogs into Perl errors, though it's
less efficient than one could wish. I don't know how to scale that
solution up to the point where you could call any random internal
backend function, as Kurt seems to be hoping for.

regards, tom lane

Peter Eisentraut wrote:
> FYI, we have received patches morally equivalent to yours many times
> over the years, and they have all been rejected. You might want to
> review the archives about that.

Hi Peter,

I went back as far as 2005 in the archives, and found only this thread
covering similar territory:

* SPI-header-files safe for C++-compiler
http://groups.google.com/group/pgsql.patches/browse_frm/thread/6dab9a8134cce102/3c91e40a9e615362?lnk=gst&q=rejected+c%2B%2B#3c91e40a9e615362
or http://tinyurl.com/6bjcdq
June 2007

That patch appears approximately equivalent to the first two of my
patches, c++reserved and c++bookends. The opposing arguments in
that thread seem strained, in my opinion, conveying more heat than
light. "Hey you kids, get off my lawn!" The conclusion of the
deliberative process wasn't set down in that thread; but evidently
the arguments in favor were not sufficiently persuasive: in the
end, the patch was not applied.

The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new occurrences be introduced.

But can we not separate the two problems of (1) actual identifiers
which prevent C++ compilation today, vs. (2) hypothetical code which
someone might submit in the future? The first problem is immediate;
the second would only be troublesome if the hypothetical identifier
makes it all the way through beta testing into a release.

Post #21 in the thread, by Tom Lane on July 4 2007 at 8:05 am,
suggests an automated check for non-C++-compilable header files,
and highlights the practical difficulties caused by lack of C++
support in the build system. To invoke the C++ compiler at
present, typically one would use a hard-wired compiler name
with hard-wired flags and paths. My third patch - c++configure -
begins to address the need for a portable way to build C++ code,
compatible with the way we build C code.

The notion of converting all of PostgreSQL to C++ was touched upon.
Little would be gained, at the cost of much tedium, so I advise
against it. I wouldn't want to redo the old stuff unless there's a
clear benefit. My proposal aims to make C++ a practical choice for
adding *new* things to PostgreSQL.

A topic of great interest is the relationship between C++ exceptions
and the PostgreSQL backend's error handling based on setjmp/longjmp.
My fourth patch - c++exception - adds a backstop to limit the damage
in case a C++ exception is thrown from anywhere in the backend and
not caught. The patch converts an uncaught exception to a PostgreSQL
FATAL error, so the process can clean itself up and report its failure
rather than just silently disappearing. If C++ code doesn't catch its
exceptions, that is a programming error, similar to a segment
violation or null pointer dereference, and worthy of termination.

These four patches aren't meant to create a palace of luxury for
C++ programmers. More could be done: more sophisticated error
handling could be provided; new/delete could be hooked up to
palloc/pfree; templates and class libraries could be written.
But C++ programmers can do these things for themselves, if we
give them a fighting chance: just take away the roadblocks
(primarily the reserved words) and make it easy to compile and
link.

Regards,
... kurt

PS. A few other threads had (at least somewhat) relevant discussion.
They're listed below. I didn't find any other patches. I'd appreciate
any links or pointers to any other threads which I should look at.

* STL problem in stored procedures
http://groups.google.com/group/pgsql.general/browse_frm/thread/ee352086139df2bf/400e8133b3e87d74?tvc=1&q=stl+problem+in+stored+procedures#400e8133b3e87d74
http://tinyurl.com/5hhf2v
October 2005

* C++ -> C : Module for converting the WHERE clause to the canonical form with PostgreSQL
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/6cb99c3521318653/d6f2b9509cda35c5?lnk=gst&q=tom+lane+c%2B%2B#d6f2b9509cda35c5
or http://tinyurl.com/6atqmq
January 2006

* PG Extensions: Must be statically linked?
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/89d3650c52430186/c63c94680b399827?lnk=gst&q=pg+extensions+must+be+statically+linked#c63c94680b399827
or http://tinyurl.com/6q5jdz
March 2006

* Writing triggers in C++
http://groups.google.com/group/pgsql.hackers/browse_frm/thread/2a95d656b8add4dd/ded7ff4ce06ae456?lnk=gst&q=writing+triggers+in+c%2B%2B#ded7ff4ce06ae456
or http://tinyurl.com/6kx8ba
February 2007

Tom Lane wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>> [ make the backend C++-compilable ]
>
> This has been proposed before, and rejected before, and I don't believe
> the arguments have changed in the least.

Hi Tom,

Of the series of four patches, the first two (c++reserved and c++bookends)
appear much the same as Jacob Rief's patch submitted in June 2007.
http://tinyurl.com/6bjcdq
(Incidentally, I only just now found that thread. I hadn't seen it
earlier because I hadn't searched the now-defunct pgsql-patches list.)

The third patch (c++configure) addresses a problem which I have not
seen discussed before: There needs to be a portable way to compile
and link C++ code.

As it stands, the third patch depends upon the first two, because the
third one can optionally compile main.c as C++. Since main.c includes
some header files in which C++ reserved words are used as identifiers,
it cannot be compiled as C++ without fixing at least a subset of those
identifiers.

However, if it is decided that the identifiers cannot be changed, then
I could revise the c++configure and c++exception patches to remove the
dependency.

Of course it can be expected that, once or twice a year, some
starry-eyed newcomer will repeat the plea for the reserved words
to be fixed, until you succumb or add it to the FAQ.

If a C++ programmer needs ereport(ERROR)s to be recast as C++
exceptions, I propose they can handle that in their own code
without special provisions being made in PostgreSQL code.
Therefore, I claim it does not need to be addressed in this
series of patches. It is a separate issue.

However, PostgreSQL code should provide a last-resort exception handler
as a backstop against C++ programming errors. That is the purpose of
the fourth patch (c++exception). C++ programmers should catch their
own exceptions, but if they let one get away, PostgresMain should try
to make sure the shared segment isn't left in a corrupt state. In
other words, PostgresMain's defense against uncaught C++ exceptions
should be approximately equivalent to its existing defense against
SIGSEGVs, null pointer dereferencing errors, and similar faults in C.

Regards,
... kurt

On Friday 05 December 2008 10:45, Kurt Harriman wrote:
> Tom Lane wrote:
> > Kurt Harriman <harriman(at)acm(dot)org> writes:
> >> [ make the backend C++-compilable ]

I tested applying this patch to CVS HEAD today and compiling
with --enable-cplusplus with gcc 4.2:

$ ldd postmaster
...
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7bf9000)
...

Then I ran pgbench and played with a table with a UUID column. Performance
was great.

(I first mistakenly applied it against a not-up-to-date source-tree ---
something from mid-September --- and that ended up not compiling.)

I still have not tried this with my own C++ code, but it seems to have less
impact on the build process than some might have feared.

--
David Lee Lambert ... Software Developer
Cell phone: +1 586-873-8813 ; alt. email <dlambert(at)bmtcarhaul(dot)com> or
<lamber45(at)msu(dot)edu>
GPG key at http://www.lmert.com/keyring.txt

On Friday 05 December 2008 09:51:50 Kurt Harriman wrote:
> Peter Eisentraut wrote:
> > FYI, we have received patches morally equivalent to yours many times
> > over the years, and they have all been rejected. You might want to
> > review the archives about that.
>
> Hi Peter,
>
> I went back as far as 2005 in the archives, and found only this thread
> covering similar territory:
>
<snip>
> The foremost opposing argument seems to have been that there
> should be no attempt to alleviate the existing reserved word
> problem without automatic enforcement to guarantee that never
> in the future can new occurrences be introduced.
>
> But can we not separate the two problems of (1) actual identifiers
> which prevent C++ compilation today, vs. (2) hypothetical code which
> someone might submit in the future? The first problem is immediate;
> the second would only be troublesome if the hypothetical identifier
> makes it all the way through beta testing into a release.
>

Actually, given your configure changes, istm a buildfarm member compiling
with --enablecplusplus would prevent any such issue from getting to far.

<snip>
>
> PS. A few other threads had (at least somewhat) relevant discussion.
> They're listed below. I didn't find any other patches. I'd appreciate
> any links or pointers to any other threads which I should look at.
>

Might I suggest you collect all of these various arguments (both for and
against) and patches into a wiki page on the developers wiki?

Also, I've no real experience in masquerading c++ as c, but the main concern I
would have is possible imcompatabilities that might be introduced between
postgresql's compiled with c++ and those compiled in c. I'm not sure there
should be any, but maybe someone with more experience in this area might have
ideas on what to watch out for?

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com

On Fri, 5 Dec 2008, Robert Treat wrote:

> Might I suggest you collect all of these various arguments (both for and
> against) and patches into a wiki page on the developers wiki?

I'm getting the feeling this is going to take a while to sort out too.
Page with most of the relevant stuff Kurt has posted so far is now listed
under Development Projects on the wiki:
http://wiki.postgresql.org/wiki/C%2B%2B_Compatibility

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith wrote:
> On Fri, 5 Dec 2008, Robert Treat wrote:
>
> > Might I suggest you collect all of these various arguments (both for and
> > against) and patches into a wiki page on the developers wiki?
>
> I'm getting the feeling this is going to take a while to sort out too.
> Page with most of the relevant stuff Kurt has posted so far is now listed
> under Development Projects on the wiki:
> http://wiki.postgresql.org/wiki/C%2B%2B_Compatibility

Is this a TODO?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Kurt Harriman wrote:
> The foremost opposing argument seems to have been that there
> should be no attempt to alleviate the existing reserved word
> problem without automatic enforcement to guarantee that never
> in the future can new occurrences be introduced.
Is there anything in the source that would necessarily preclude using the
C++ compiler to build *all* the code?

I'd guess that this would be quite a big patch to do this in any places
where we have implicit conversions from void* to char* etc, but
the result is valid as C and C++ and arguably better documented.

C++ is picky about a few things you can do in C, but most of them
are things I'd rather not do anyway.

Run such a build on the build farm each night, and it will be obvious as
soon as C++-unfriendly code sneaks in.

And who know, maybe eventually we could use C++ properly in the
code.

James

On Saturday 06 December 2008 22:38:29 James Mansion wrote:
> Kurt Harriman wrote:
> > The foremost opposing argument seems to have been that there
> > should be no attempt to alleviate the existing reserved word
> > problem without automatic enforcement to guarantee that never
> > in the future can new occurrences be introduced.
>
> Is there anything in the source that would necessarily preclude using the
> C++ compiler to build *all* the code?

Probably lots, but that's not the problem we are trying to solve here. And
many people are seriously not interested in using C++ for PostgreSQL.

Peter Eisentraut wrote:
> On Saturday 06 December 2008 22:38:29 James Mansion wrote:
>
>> Kurt Harriman wrote:
>>
>>> The foremost opposing argument seems to have been that there
>>> should be no attempt to alleviate the existing reserved word
>>> problem without automatic enforcement to guarantee that never
>>> in the future can new occurrences be introduced.
>>>
>> Is there anything in the source that would necessarily preclude using the
>> C++ compiler to build *all* the code?
>>
>
> Probably lots, but that's not the problem we are trying to solve here. And
> many people are seriously not interested in using C++ for PostgreSQL.
>
>

The most serious problem AFAIK is that we use setjmp/longjmp, which I
understand does not play at all nicely with C++ exceptions.

cheers

andrew

Andrew Dunstan wrote:
> The most serious problem AFAIK is that we use setjmp/longjmp, which I
> understand does not play at all nicely with C++ exceptions.

Considering the complexity of the code and how it at times stretches the
C standard to the point of cheating, I think anyone's three-item list of
major problems is going to be much too short.

> Is there anything in the source that would necessarily preclude using the
> C++ compiler to build *all* the code?

No. Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added. Some files would need more widespread (but still
trivial) changes, such as renaming local variables or
parameters which are C++ reserved words. There are a few
head-scratchers: see this post (1 July 2007)
http://groups.google.com/group/pgsql.patches/msg/91775dc1355cdc72
or http://tinyurl.com/6a67ms

I've actually gone through the tedious experiment of fixing up
about 40 of the source files so they can be compiled as either
C or C++. With these files compiled as C++, and the remainder
compiled as C, PostgreSQL builds successfully and passes the
'make check' regression tests. The intermixture of C together
with C-compiled-as-C++ works just fine, at least on my x86-32
Linux platform. On the other hand, PostgreSQL already works
as C; trying to convert it all to C++ doesn't seem useful.

Suppose we were to use the C++ compiler to build all of
PostgreSQL. Consider the alternatives: either

A) switch over entirely to C++, no longer supporting C; or

B) let the build farm do a nightly build with a C++ compiler
merely as a test to verify that no C++ compilation errors
are introduced, but continue to use C 'officially' for
builds and releases; or

C) support C and C++ equally, allowing the choice to be made
by each person who builds PostgreSQL from source.

Alternative A breaks (almost?) all existing third party
extension code: sufficient reason to rule out this alternative.

With Alternative B, most development work would probably still
be done in C. C programmers surely won't embrace the idea
that they should conform to C++ rules and take care that their
C code is C++-compilable. Some of the C++ rules are obscure;
rare is the C++ programmer who never omits a needed cast.
Every patch will have to be checked for C++ compatibility.
If the build farm detects a C++ error, likely one of the
committers would be saddled with the burden of backing
out the patch and/or correcting the error.

Alternative C seems to just about double the amount of work
involved in every commit, build, and release. Again, much
of the burden probably falls on the committers.

All the extra work and trouble will be justified if there is
a truly spectacular payoff. What magnificence awaits us when
all of PostgreSQL is C++-compilable? I don't have a good
answer.

The best alternative, in my opinion, is "none of the above".
That's why I have instead offered some patches to enable C++
for new extensions and add-on development with minimal
impact to the C core.

As a courteous host, one might extend hospitality to a guest,
but not indeed go so far as to redecorate the house from top
to bottom to suit the guest's taste.

Regards,
... kurt

James Mansion wrote:
> Is there anything in the source that would necessarily preclude using the
> C++ compiler to build *all* the code?
>
> I'd guess that this would be quite a big patch to do this in any places
> where we have implicit conversions from void* to char* etc, but
> the result is valid as C and C++ and arguably better documented.
>
> C++ is picky about a few things you can do in C, but most of them
> are things I'd rather not do anyway.
>
> Run such a build on the build farm each night, and it will be obvious as
> soon as C++-unfriendly code sneaks in.
>
> And who know, maybe eventually we could use C++ properly in the
> code.
>
> James

Kurt Harriman <harriman(at)acm(dot)org> writes:
> Suppose we were to use the C++ compiler to build all of
> PostgreSQL. Consider the alternatives: either

> A) switch over entirely to C++, no longer supporting C; or

> B) let the build farm do a nightly build with a C++ compiler
> merely as a test to verify that no C++ compilation errors
> are introduced, but continue to use C 'officially' for
> builds and releases; or

> C) support C and C++ equally, allowing the choice to be made
> by each person who builds PostgreSQL from source.

> Alternative A breaks (almost?) all existing third party
> extension code: sufficient reason to rule out this alternative.

This project isn't even willing to require that people use a C99
compiler ... you won't get far suggesting that the minimum tool be
upped to C++.

> With Alternative B, most development work would probably still
> be done in C.

s/most/all/, at least for anything that has ambitions of getting into
the core distribution. You can't code in C++ if it needs to be
C-compilable. For the same reason, I don't think alternative C is
materially different from alternative B: either way the rule is
"Write C that doesn't give a C++ compiler indigestion".

> All the extra work and trouble will be justified if there is
> a truly spectacular payoff. What magnificence awaits us when
> all of PostgreSQL is C++-compilable? I don't have a good
> answer.

Given the above constraints, I think the only real role for C++ here
would be to allow access to third-party C++ libraries as Postgres
extensions --- for instance something like an XML or numerical analysis
library. Now by definition such libraries aren't trying to call into
any core Postgres code, so it doesn't seem like converting all the
headers to be C++-safe is really an especially useful goal anyhow.
There's a subset of headers, like fmgr.h and funcapi.h, that would be
needed by the interface layer for such a project, and maybe they should
be made C++-clean.

The stumbling block, though, remains the same as I mentioned in the
message you linked to: if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty. So it
seems like we have a very high initial investment to obtain something
that is really of unclear value.

regards, tom lane

I wrote:
> The stumbling block, though, remains the same as I mentioned in the
> message you linked to: if we fix some or all of the headers, what's the
> plan for making sure that they stay fixed? Without a C++ buildfarm
> member I think the chances of future breakage approach certainty.

Actually, after re-reading the whole earlier thread I see that we did
think of a possible answer to that:
http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php
which in fact is on the TODO list now. So if someone wanted to step
up and make that happen, it would become sane to try to have C++-clean
headers.

regards, tom lane

Tom Lane wrote:
>
> Given the above constraints, I think the only real role for C++ here
> would be to allow access to third-party C++ libraries as Postgres
> extensions --- for instance something like an XML or numerical analysis

I seem to recall that we're already able to do this.

IIRC, some older postgis's wrapped some C++ library that they
used internally; and some of my old scripts for installing
postgres have: "env LDFLAGS=-lstdc++ ./configure --prefix=$PGHOME"

I guess existing current c++ postgres extensions probably have a C wrapper?
and I guess the main benefit of this project would be that the C wrapper
could be thinner (or even nonexistant?) with these proposed changes?

Tom Lane wrote:
>> if we fix some or all of the headers, what's the
>> plan for making sure that they stay fixed? Without a C++ buildfarm
>> member I think the chances of future breakage approach certainty.
>
> Actually, after re-reading the whole earlier thread I see that we did
> think of a possible answer to that:
> http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php
> which in fact is on the TODO list now. So if someone wanted to step
> up and make that happen, it would become sane to try to have C++-clean
> headers.

I'd be happy to work on that.

However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.

This would build one file - main.c - as C++ (necessary
because on some platforms the main() function needs to be
C++ to ensure the C++ runtime library is initialized).
The C++ compilation of main.c will fail if any C++
reserved words have been used as identifiers in the headers
included there. main.c already pulls in most of the headers
which are of interest for calling back in to postgres
(see attached .svg file). To complete the set, I could add
#include's for funcapi.h and spi.h.

C++-clean headers should be far less burdensome than trying
to keep the whole codebase C++-clean, because it is not very
often that someone would inadvertently choose a C++ reserved
word to use as a new field name or identifier in one of these
.h files; and main.c is not often changed.

(One of my patches - c++exception - adds a second file to
be C++ compiled (postgres.c). I'm planning to revise that
patch so that only main.c gets C++ compiled, to reduce the
exposure to inadvertent breakage of the --enable-cplusplus
build.)

Would it be worthwhile to make all the headers C++-clean,
rather than just the ones which seem likely to be pulled
in by a new access method, data type, or programming
language? The pgcompinclude proposal would be attractive
if every header file needs to be checked. (My opinion:
do that only if somebody needs it.)

Regards,
... kurt

... forgot to attach the .svg file showing the files
#included by main.c. Here it is.

Kurt Harriman <harriman(at)acm(dot)org> writes:
> However, probably an easier alternative would be to have
> just one buildfarm machine do a nightly build configured
> with the --enable-cplusplus option.

There is no such option, and won't be.

> This would build one file - main.c - as C++ (necessary
> because on some platforms the main() function needs to be
> C++ to ensure the C++ runtime library is initialized).

Useless, since main.c doesn't include any large number of headers,
and in particular there is no reason for it to include the headers
that are critical to function libraries.

regards, tom lane

Tom Lane wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>> However, probably an easier alternative would be to have
>> just one buildfarm machine do a nightly build configured
>> with the --enable-cplusplus option.

> There is no such option, and won't be.

Yours is the first comment anyone has posted to the list
regarding my proposed c++configure patch, and it sounds
alarmingly definite.

May I ask you to elaborate? Have you more to say on the
subject?

>> This would build one file - main.c - as C++ (necessary
>> because on some platforms the main() function needs to be
>> C++ to ensure the C++ runtime library is initialized).
>
> Useless, since main.c doesn't include any large number of headers,

main.c directly or indirectly includes these 71 headers:
access/attnum.h access/genam.h access/heapam.h
access/htup.h access/rmgr.h access/sdir.h
access/skey.h access/tupdesc.h access/tupmacs.h
access/xlog.h access/xlogdefs.h bootstrap/bootstrap.h
c.h catalog/genbki.h catalog/pg_am.h
catalog/pg_attribute.h catalog/pg_class.h catalog/pg_index.h
executor/execdesc.h executor/tuptable.h fmgr.h
lib/stringinfo.h nodes/bitmapset.h nodes/execnodes.h
nodes/nodes.h nodes/params.h nodes/parsenodes.h
nodes/pg_list.h nodes/plannodes.h nodes/primnodes.h
nodes/tidbitmap.h nodes/value.h pg_config.h
pg_config_manual.h pg_config_os.h pgtime.h
port.h postgres.h postgres_ext.h
postmaster/postmaster.h rewrite/prs2lock.h storage/backendid.h
storage/block.h storage/buf.h storage/bufpage.h
storage/item.h storage/itemid.h storage/itemptr.h
storage/lock.h storage/lwlock.h storage/off.h
storage/relfilenode.h storage/shmem.h tcop/dest.h
tcop/tcopprot.h utils/array.h utils/elog.h
utils/errcodes.h utils/guc.h utils/help_config.h
utils/hsearch.h utils/int8.h utils/palloc.h
utils/pg_crc.h utils/pg_locale.h utils/ps_status.h
utils/rel.h utils/relcache.h utils/snapshot.h
utils/timestamp.h utils/tuplestore.h

> and in particular there is no reason for it to include the headers
> that are critical to function libraries.

Extra #includes could be added to main.c just for the purpose of
getting them C++-syntax-checked. Or, a few more .c files could be
chosen to expand the set of C++-syntax-checked headers. For
instance, xml.c pulls in spi.h and 96 other headers. 66 of them
overlap with main.c; but these 31 are new:
access/xact.h catalog/namespace.h catalog/pg_language.h
catalog/pg_proc.h catalog/pg_type.h commands/dbcommands.h
executor/execdefs.h executor/executor.h executor/spi.h
lib/dllist.h libpq/pqformat.h mb/pg_wchar.h
miscadmin.h nodes/memnodes.h nodes/nodeFuncs.h
nodes/relation.h tcop/pquery.h tcop/utility.h
utils/builtins.h utils/catcache.h utils/date.h
utils/datetime.h utils/datum.h utils/lsyscache.h
utils/memutils.h utils/plancache.h utils/portal.h
utils/resowner.h utils/syscache.h utils/tzparser.h
utils/xml.h
funcapi.h is still missing. One file that includes it is
pl_exec.c, which pulls in 8 more headers not already listed:
access/transam.h commands/trigger.h executor/spi_priv.h
funcapi.h parser/scansup.h plpgsql.h
utils/snapmgr.h utils/typcache.h
So C++-compiling just a few source files is sufficient to syntax
check a useful subset of header files including those which are
most important for add-on development.

However, the above approach has a couple of obvious caveats:

:( It doesn't give C++ users a precise specification of exactly
which header files they may rely upon from release to release.

:( From time to time, C++ programmers will probably come along
asking for even more header files to be sanitized.

The alternative which you have suggested, using pgcompinclude,
could solve these caveats by enforcing C++ safety upon every
PostgreSQL header file. And it would not require any more .c
files beyond main.c to be kept C++-clean.

http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php

I'll get started on the pgcompinclude thing.

Regards,
... kurt

Kurt Harriman wrote:
> B) let the build farm do a nightly build with a C++ compiler
> merely as a test to verify that no C++ compilation errors
> are introduced, but continue to use C 'officially' for
> builds and releases; or
This was the intent of my suggestion.

There can be advantages in that you can use a lot of C99 (and
still port to non-C99 envs eg MSVC) if you have a few ifdefs
to use std::vector instead of dynamic arrays, but the bigger issue
(for me) was always been that the name mangling means that
you find out pretty quickly if you have a mismatch between
declaration and definition of functions.

Attempting the link with C++ mangling can put this to rest,
even if you never try running it.

>>> Kurt Harriman <harriman(at)acm(dot)org> wrote:
> That's why I have instead offered some patches to enable C++
> for new extensions and add-on development with minimal
> impact to the C core.

I've been a bit confused by this thread. We wrote a couple PostgreSQL
functions (pdftotext and pdfisok) which use libpoppler. It didn't
seem very hard to do without any of this. Granted, it isn't likely to
be portable to all environments, which is why we haven't bothered to
try to put it out for the community; but there didn't seem to be any
great barriers for our environment (SuSE/gcc). Is this intended to
make such efforts more portable, so they can be shared with more
environments?

Did we just get lucky?

-Kevin

P.S. Our environment:

PostgreSQL 8.3.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20070115 (SUSE Linux)

[ just realized that I set this message aside to reply to later, and
then forgot about it --- apologies ]

Kurt Harriman <harriman(at)acm(dot)org> writes:
> Tom Lane wrote:
>> There is no such option, and won't be.

> Yours is the first comment anyone has posted to the list
> regarding my proposed c++configure patch, and it sounds
> alarmingly definite.
> May I ask you to elaborate? Have you more to say on the
> subject?

Well, as I understand it the proposal is to build main.c as C++ in the
hope of (1) identifying C++ incompatibilities in our include headers,
and (2) linking C++ instead of C library on platforms where they are
different.

As for #1, main.c doesn't (and shouldn't) include a large fraction of
the headers that might be interesting to a C++ add-on --- I'm surprised
that it hits as many as it does, because it surely has no direct use
for most of them.

> Extra #includes could be added to main.c just for the purpose of
> getting them C++-syntax-checked.

They'd disappear again the next time Bruce runs his unnecessary-#include
elimination script. And anyway the vast majority of the inclusions you
show here are accidental, indirect inclusions that might go away in any
header refactoring.

As for #2, thanks but no thanks: the very last thing I want is to have a
switch that causes us to start running on a different basic C library.
That would open all sorts of portability and testability concerns.
AFAIK there are only a few obsolete platforms where a C++-specific libc
is needed, and I'm perfectly happy to blow off the idea of supporting
C++ add-ons on them.

So I'm willing to support a project of making *all* our headers (or at
least all the ones a C++ addon could possibly care about) C++-safe,
if there's buildfarm support for making sure they stay that way. But
I don't approve of changing the way main.c gets compiled.

I am, btw, still waiting for an actually plausible use-case for this.
AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
what you could hope to accomplish by importing a pile of C++ code.

regards, tom lane

Tom Lane wrote:
> I am, btw, still waiting for an actually plausible use-case for this.
> AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
> what you could hope to accomplish by importing a pile of C++ code.

The one use-case I can think of that imports a pile of C++ code
is the GEOS library that PostGIS uses (used?):

http://postgis.refractions.net/support/wiki/index.php?GEOS
"GEOS is a C++ port of the JTS Topology Suite. It is used by PostGIS to
implement Topological functions. "

However it seems to work fine even without the C++-header project,
so I must be missing something here...

Ron Mayer wrote:
> Tom Lane wrote:
>> I am, btw, still waiting for an actually plausible use-case for this.
>> AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
>> what you could hope to accomplish by importing a pile of C++ code.
>
> The one use-case I can think of that imports a pile of C++ code
> is the GEOS library that PostGIS uses (used?):

There are also quite a number of OSS algorithms, useful for query
optimization or otherwise, which are written in C++. For example, the
fully OSS implementation of annealing (potentially useful as a
replacement for GEQO) is in C++.

However, the real reason to do this is to attract C++ hackers to hack on
PostgreSQL and extend it. Most of what makes PostgreSQL cool now we got
because PostgreSQL is so easy for C geeks to hack on. Who knows what
the C++ crowd will contribute if given the opportunity? It's not the
stuff we *know* we can get which is exciting, it's the stuff we don't
know about.

(and yes, I realize this would hold true of other programming languages
as well. However, we can't support them as easily as C++)

As the Guy Who Is Obsessed With Making Our Community Grow (GWIOWMOCG), I
strongly support this goal. Although the other issues like breakage
need fixing.

--Josh

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Ron Mayer wrote:
>> The one use-case I can think of that imports a pile of C++ code
>> is the GEOS library that PostGIS uses (used?):

> There are also quite a number of OSS algorithms, useful for query
> optimization or otherwise, which are written in C++. For example, the
> fully OSS implementation of annealing (potentially useful as a
> replacement for GEQO) is in C++.

Well, if we were actually contemplating using it, we'd rewrite it in C.
I don't see anyone around here who's in favor of increasing the minimum
build requirement to C++. (Even if we were, there's exactly 0 chance
that an existing hunk of C++ code would follow our error handling and
memory allocation conventions, so we'd have to do significant rewriting
anyway.)

The PostGIS-style case, where someone writes some code to provide a
mostly arm's-length interface to an external library written in C++,
is the only case I can see much use for. And that still leaves me
wondering what's the point of making our headers C++ clean, because
that external library isn't gonna include 'em anyway.

regards, tom lane

Added to TODO:

Allow C++ code to more easily access backend code

* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php

---------------------------------------------------------------------------

Kurt Harriman wrote:
> > Is there anything in the source that would necessarily preclude using the
> > C++ compiler to build *all* the code?
>
> No. Most of the source files would need a sprinkling of
> tiny changes: typically only a handful of casts need to be
> added. Some files would need more widespread (but still
> trivial) changes, such as renaming local variables or
> parameters which are C++ reserved words. There are a few
> head-scratchers: see this post (1 July 2007)
> http://groups.google.com/group/pgsql.patches/msg/91775dc1355cdc72
> or http://tinyurl.com/6a67ms
>
> I've actually gone through the tedious experiment of fixing up
> about 40 of the source files so they can be compiled as either
> C or C++. With these files compiled as C++, and the remainder
> compiled as C, PostgreSQL builds successfully and passes the
> 'make check' regression tests. The intermixture of C together
> with C-compiled-as-C++ works just fine, at least on my x86-32
> Linux platform. On the other hand, PostgreSQL already works
> as C; trying to convert it all to C++ doesn't seem useful.
>
> Suppose we were to use the C++ compiler to build all of
> PostgreSQL. Consider the alternatives: either
>
> A) switch over entirely to C++, no longer supporting C; or
>
> B) let the build farm do a nightly build with a C++ compiler
> merely as a test to verify that no C++ compilation errors
> are introduced, but continue to use C 'officially' for
> builds and releases; or
>
> C) support C and C++ equally, allowing the choice to be made
> by each person who builds PostgreSQL from source.
>
> Alternative A breaks (almost?) all existing third party
> extension code: sufficient reason to rule out this alternative.
>
> With Alternative B, most development work would probably still
> be done in C. C programmers surely won't embrace the idea
> that they should conform to C++ rules and take care that their
> C code is C++-compilable. Some of the C++ rules are obscure;
> rare is the C++ programmer who never omits a needed cast.
> Every patch will have to be checked for C++ compatibility.
> If the build farm detects a C++ error, likely one of the
> committers would be saddled with the burden of backing
> out the patch and/or correcting the error.
>
> Alternative C seems to just about double the amount of work
> involved in every commit, build, and release. Again, much
> of the burden probably falls on the committers.
>
> All the extra work and trouble will be justified if there is
> a truly spectacular payoff. What magnificence awaits us when
> all of PostgreSQL is C++-compilable? I don't have a good
> answer.
>
> The best alternative, in my opinion, is "none of the above".
> That's why I have instead offered some patches to enable C++
> for new extensions and add-on development with minimal
> impact to the C core.
>
> As a courteous host, one might extend hospitality to a guest,
> but not indeed go so far as to redecorate the house from top
> to bottom to suit the guest's taste.
>
> Regards,
> ... kurt
>
> James Mansion wrote:
> > Is there anything in the source that would necessarily preclude using the
> > C++ compiler to build *all* the code?
> >
> > I'd guess that this would be quite a big patch to do this in any places
> > where we have implicit conversions from void* to char* etc, but
> > the result is valid as C and C++ and arguably better documented.
> >
> > C++ is picky about a few things you can do in C, but most of them
> > are things I'd rather not do anyway.
> >
> > Run such a build on the build farm each night, and it will be obvious as
> > soon as C++-unfriendly code sneaks in.
> >
> > And who know, maybe eventually we could use C++ properly in the
> > code.
> >
> > James
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Friday 05 December 2008 11:16:37 Kurt Harriman wrote:
> Just a few additional header files are mentioned in the PostgreSQL
> Reference Manual for add-on developers to use: fmgr.h, funcapi.h,
> and spi.h. This patch adds bookends within those three files for
> the benefit of beginners writing very simple extensions in C++.

I have signed up to review this patch series for the commit fest.

I can try to debunk this approach for selecting the files to add C++
decorations in: A grep through contrib/, which includes a variety of simple
and complex extensions, shows a count of 80 different backend includes being
used.

So I think either decoration is added to all of these files or none of them.
And I think the former is not going to go over well.

> Documentation and learning are simplified because C example code
> can be compiled as C or C++ without change.

I think having some subset of header files work with C++ without extra
decoration and some only with extra decoration will not necessarily improve
documentation and learning. Forcing people to add the decorations around
PostgreSQL backend header files will at least make them remember what they are
dealing with.

On Friday 05 December 2008 11:18:46 Kurt Harriman wrote:
> This patch adds C++ support to the PostgreSQL build system.

Unless you can provide a significant specific use case, I think this patch is
rejected. Building part of PostgreSQL sometimes with C++ would just add too
much uncertainty and maintenance overhead without a known benefit.

On Friday 05 December 2008 11:13:37 Kurt Harriman wrote:
> Fortunately, there are not many instances which are likely
> to be encountered by our C++ guests, and these can easily
> be changed. In memnodes.h, parsenodes.h, and primnodes.h,
> this patch changes the following field names:
>
> typename => typeName
> typeid => typeOid
> using => usingClause
> delete => delete_context
>
> Also, the patch changes a few parameter names in function
> prototypes in makefuncs.h, parse_type.h, and builtins.h:
>
> typename => typeName
> typeid => typeOid
> namespace => qualifier

I'll see if I can adjust pgcompinclude for checking C++ compatibility of
headers automatically. If we have such a tool, this patch should be OK to go
in.

On Friday 05 December 2008 11:13:37 Kurt Harriman wrote:
> 1. c++reserved

I have applied (an extended version of) this patch.

On Mon, Jul 13, 2009 at 5:51 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> So I think either decoration is added to all of these files or none of them.
> And I think the former is not going to go over well.

We do have some things that are conditioned on __cplusplus already,
such as "c.h", "pg_config.h.in", and "postgres_ext.h". So at some
point we at least thought about supporting inclusion of our header
files from C++. But I agree that if we're going to do it at all, we
ought to do it everywhere.

...Robert

On Thursday 16 July 2009 17:00:03 Robert Haas wrote:
> On Mon, Jul 13, 2009 at 5:51 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> > So I think either decoration is added to all of these files or none of
> > them. And I think the former is not going to go over well.
>
> We do have some things that are conditioned on __cplusplus already,
> such as "c.h", "pg_config.h.in", and "postgres_ext.h". So at some
> point we at least thought about supporting inclusion of our header
> files from C++. But I agree that if we're going to do it at all, we
> ought to do it everywhere.

We do support using the frontend headers (libpq, ecpg) from C++. That's what
postgres_ext.h is about. The code in pg_config.h.in is autogenerated by
Autoconf. The stuff in c.h is probably still there from before we rearranged
the header files so that the frontend includes don't use c.h.