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

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

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:49:40
Message-ID: 1183009780.6094.19.camel@goldbach (view raw or flat)
Thread:
Lists: pgsql-patches
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 (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 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. Doing
"s/typename/type_name/g" is likely to be the least of your concerns if
your extension integrates with Postgres that closely.

It would be one thing if we made a significant effort to preserve
internal API stability -- but we plainly do not. (See the varlena API
changes made in 8.3 for an example of an API change that will break far
more user-written extensions.)

> The *real* problem here is that to make this useful, we have to buy into
> the assumption that C++ should work in the backend.

I agree that C++ in the backend is always going to be a little hokey,
but (a) I don't agree that it is completely impossible (b) if we can
make people's lives a bit easier, I don't see a good reason not to. Like
it or not, people have called into C++ libraries from C UDFs in the
past, and likely will do so in the future.

> The error handling assumptions are completely incompatible (setjmp and
> throw do not usually interoperate)

AFAIK this is resolvable with some degree of pain: before entering C++
land, wrap the call site in a C++ exception handler, and before calling
back into Postgres, use a PG_TRY() block to rethrow elog(ERROR) as a C++
exception (and then rethrow as an elog(ERROR) once you've unwound the
C++ portion of the stack) ... hey, I didn't say it was clean ;-)

It's also worth noting that some people use C++ as "C with classes", and
disallow the use of exceptions, RTTI, and that sort of stuff. Calling
into such code from the backend is marginally more sane.

-Neil



In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-06-28 06:07:52
Subject: Re: SPI-header-files safe for C++-compiler
Previous:From: Tom LaneDate: 2007-06-28 05:15:45
Subject: Re: SPI-header-files safe for C++-compiler

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