From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Cc: | David Gross <David(dot)Gross(at)lri(dot)fr> |
Subject: | Re: [HACKERS] using C++ to define new functions |
Date: | 1998-07-20 14:48:11 |
Message-ID: | 14641.900946091@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michal Mosiewicz <mimo(at)interdata(dot)com(dot)pl> writes:
> David Gross wrote:
>> but the linking style of c++ is rather different.
>> Do you have an idea ?
> How about using extern "C" {...} ?
I think the major problem here is that David would probably like the
constructors for any global-level variables in his C++ code to be called
when his shared library is loaded into the backend. (If his C++ code
hasn't got *any* global variables with nontrivial constructors, then
he could maybe survive without this. But it'd be a necessary part of
a general-purpose solution.)
This is doable. I routinely use a system that does dynamic loading
of C++ code (Ptolemy, http://ptolemy.eecs.berkeley.edu) It's fairly
messy and unportable however, because you have to be aware of the
machine-and-compiler-dependent conventions for naming and finding
the global constructors.
David would probably also want to link the C++ library into the backend
(as a shared library, otherwise the linker will optimize it away) so
that his shared library doesn't need to include C++ library routines.
There might be a few other little changes to make in the link that
builds the backend.
In short, this could be supported if we wanted to invest a sufficient
amount of effort in it. I'm not sure it's worth the trouble.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gene Selkov, Jr. | 1998-07-20 14:51:05 | Re: [GENERAL] Recalling previous commands at the PSQL prompt |
Previous Message | D'Arcy J.M. Cain | 1998-07-20 13:22:14 | Finding primary keys in a table |