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
