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"
On Feb 14, 11:26 am, [EMAIL PROTECTED] ("Florian G. Pflug") wrote:
> Neil Conway wrote:
> > On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
> >> Probably stack allocation doesn't matter much, as I think that would be
> >> unwinded by the longjmp call. I don't know a lot about C++, but if
Florian G. Pflug writes:
>>> Maybe we should create some wiki page or pgfoundry project that collects
>>> all glue code, tipps and tricks that people invented to glue C++ into
>>> the postgres backend.
>>
>> If it can be made to work, sure; in techdocs.
>
> I was thinking that two pairs of macros,
Neil Conway wrote:
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call. I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed.
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating envi
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
> Probably stack allocation doesn't matter much, as I think that would be
> unwinded by the longjmp call. I don't know a lot about C++, but if
> there are allocations in the data area then those would probably not be
> freed. But it makes m
Florian G. Pflug wrote:
> Alvaro Herrera wrote:
> >Florian G. Pflug wrote:
> >>Andreas Pflug wrote:
> >>>Tom Lane wrote:
> Jacob Rief <[EMAIL PROTECTED]> writes:
>
> >I tried to write a trigger using C++.
> >
> That is most likely not going to work anyway, because the backe
Alvaro Herrera wrote:
Florian G. Pflug wrote:
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down eno
Florian G. Pflug wrote:
> Andreas Pflug wrote:
> >Tom Lane wrote:
> >>Jacob Rief <[EMAIL PROTECTED]> writes:
> >>
> >>>I tried to write a trigger using C++.
> >>>
> >>That is most likely not going to work anyway, because the backend
> >>operating environment is C not C++. If you dumb it down
Andreas Pflug wrote:
Tom Lane wrote:
Jacob Rief <[EMAIL PROTECTED]> writes:
I tried to write a trigger using C++.
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++
Tom Lane wrote:
> Jacob Rief <[EMAIL PROTECTED]> writes:
>
>> I tried to write a trigger using C++.
>>
>
> 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
Jacob Rief <[EMAIL PROTECTED]> writes:
> I tried to write a trigger using C++.
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 poi
Jacob Rief wrote:
> 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?
Couldn't you do the required renamings as preprocessor
I tried to write a trigger using C++. This requires to include the
following header-files:
extern "C" {
#include
#include
#include
#include
}
Unfortunately some of the included headers define some structs and
functions where a few identifiers are C++ keywords.
The compiler-directive 'extern "
14 matches
Mail list logo