Skip site navigation (1) Skip section navigation (2)

Re: SPI-header-files safe for C++-compiler

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Jacob Rief <jacob(dot)rief(at)gmx(dot)at>, pgsql-patches(at)postgresql(dot)org
Subject: Re: SPI-header-files safe for C++-compiler
Date: 2007-06-28 05:15:45
Message-ID: 20787.1183007745@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Wed, 2007-06-27 at 20:51 -0400, Andrew Dunstan wrote:
>> He's used the usual "#ifdef __cplusplus" wrapper - isn't that good enough?

> Well, there's nothing wrong with it per se, I'm just wondering (1) what
> the proper set of headers to add it to is -- the patch just does a
> handful (2) whether we need to bother doing it at all -- can't clients
> do the extern "C" trick before including any Postgres headers?

The whole thing has been proposed before and rejected before.

The patch as given merely renames some random identifiers that happen to
be keywords in some non-C language (thereby breaking not only a lot of
core backend code, which we can fix, but who knows what other
user-written extensions that we can't fix so easily).  The *real*
problem here is that to make this useful, we have to buy into the
assumption that C++ should work in the backend.  The error handling
assumptions are completely incompatible (setjmp and throw do not usually
interoperate), and there are a lot of other bits of infrastructure that
C++ expects that are not likely to be in a C-based executable either.

I might be willing to accept this patch if I thought it were the end of
the story, but I know that it is only the camel's nose poking under the
tent.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Neil ConwayDate: 2007-06-28 05:49:40
Subject: Re: SPI-header-files safe for C++-compiler
Previous:From: Neil ConwayDate: 2007-06-28 00:54:47
Subject: Re: SPI-header-files safe for C++-compiler

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group