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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-28 06:07:52 | Re: SPI-header-files safe for C++-compiler |
Previous Message | Tom Lane | 2007-06-28 05:15:45 | Re: SPI-header-files safe for C++-compiler |