Tom Lane wrote:
> That is most likely not going to work anyway, because the backend
> operating environment is C not C++. If you dumb it down enough
> --- no exceptions, no RTTI, no use of C++ library --- then it might
> work, but at that point you're really coding in C anyway.
Writing "normal" user-defined-functions in C++ is not a problem so far.
I even handle C++ exceptions, by catching each C++ exception inside my
functions. The catch()-blocks in those functions raise
Postgres-exceptions using elog in case of a throw(). Writing "normal"
user-defined-functions in C++ is even encouraged by the documentation,
which says: "User-defined functions can be written in C (or a language
that can be made compatible with C, such as C++)." [chapter 33.9.]
The question is, why not writing user-defined trigger-functions in
C++ ? The difference between a "normal" function and a trigger function
is not that big although. The "big" difference is, that one must include
some more header-files (executor/spi.h and commands/trigger.h) which
themselves include other headers-files containing identifiers which
unfortunately are C++-keywords.
> > Is there any convention how to rename such identifiers? If I would
> > rename those identifiers (I simply would add an underscore to each of
> > them), would such a patch be accepted and adopted onto one of the next
> > releases?
>
> No. Because of the above problems, we don't see much reason to avoid
> C++'s extra keywords.
In order to check how much code would be have to be changed, I renamed
the affected keywords in the Postgres-8.2.3-headers files, patched the
affected sources and recompiled the code. The resulting patch affects
only 189 lines of code in 23 files.
Applying this patch would encourage authors of external trigger
functions to write their code in C++ instead of using PL/SQL and calling
"normal" user-defined functions, or writing wrappers in C to hide the
C++-keywords.
I will recreate this patch for the CVS-head of the repository, if there
are chances that it ever will be commitet.
Regards, Jacob
