Re: SPI-header-files safe for C++-compiler - Mailing list pgsql-patches

From Tom Lane
Subject Re: SPI-header-files safe for C++-compiler
Date
Msg-id 21378.1183010872@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI-header-files safe for C++-compiler  (Neil Conway <neilc@samurai.com>)
Responses Re: SPI-header-files safe for C++-compiler  (Neil Conway <neilc@samurai.com>)
Re: SPI-header-files safe for C++-compiler  ("Jacob Rief" <jacob.rief@gmx.at>)
Re: SPI-header-files safe for C++-compiler  ("Jacob Rief" <jacob.rief@gmx.at>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> On Thu, 2007-28-06 at 01:15 -0400, Tom Lane wrote:
>> The patch as given merely renames some random identifiers that happen to
>> be keywords in some non-C language ...

> The fact is, any user-written extensions that depend on types defined in
> parsenodes.h and primnodes.h are going to get broken all the time
> *anyway*, so I don't see this as a major disadvantage.

Sure, but we don't break them just on a whim.  The bottom line here is
whether we are going to make a real commitment to making C++ usable as
a backend extension language --- and for the reasons I mentioned, that
would entail a lot more than renaming a few identifiers.  It was already
pointed out upthread that wrapping the inclusions in extern "C" {...}
would fix the identifier part of the problem from the user side, so I do
not see the point of fixing it from our side unless we are prepared to
buy into a lot of other changes.  A C++ writer who is unwilling to add
the extern{} bit around inclusions of C headers seems unlikely to "work
with us" as regards to error-throwing conventions, for instance.

            regards, tom lane

pgsql-patches by date:

Previous
From: Neil Conway
Date:
Subject: Re: SPI-header-files safe for C++-compiler
Next
From: Neil Conway
Date:
Subject: Re: SPI-header-files safe for C++-compiler