Re: SPI-header-files safe for C++-compiler
От | Neil Conway |
---|---|
Тема | Re: SPI-header-files safe for C++-compiler |
Дата | |
Msg-id | 1183009780.6094.19.camel@goldbach обсуждение исходный текст |
Ответ на | Re: SPI-header-files safe for C++-compiler (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SPI-header-files safe for C++-compiler
|
Список | 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
В списке pgsql-patches по дате отправления: