Kurt Harriman harri...@acm.org wrote:
That's why I have instead offered some patches to enable C++
for new extensions and add-on development with minimal
impact to the C core.
I've been a bit confused by this thread. We wrote a couple PostgreSQL
functions (pdftotext and pdfisok) which use
[ just realized that I set this message aside to reply to later, and
then forgot about it --- apologies ]
Kurt Harriman harri...@acm.org writes:
Tom Lane wrote:
There is no such option, and won't be.
Yours is the first comment anyone has posted to the list
regarding my proposed
Tom Lane wrote:
I am, btw, still waiting for an actually plausible use-case for this.
AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
what you could hope to accomplish by importing a pile of C++ code.
The one use-case I can think of that imports a pile of C++ code
is the
Ron Mayer wrote:
Tom Lane wrote:
I am, btw, still waiting for an actually plausible use-case for this.
AFAICS the setjmp-vs-exceptions thing puts a very serious crimp in
what you could hope to accomplish by importing a pile of C++ code.
The one use-case I can think of that imports a pile of
Josh Berkus j...@agliodbs.com writes:
Ron Mayer wrote:
The one use-case I can think of that imports a pile of C++ code
is the GEOS library that PostGIS uses (used?):
There are also quite a number of OSS algorithms, useful for query
optimization or otherwise, which are written in C++. For
Added to TODO:
Allow C++ code to more easily access backend code
* http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php
---
Kurt Harriman wrote:
Is there anything in the source that would
Kurt Harriman wrote:
B) let the build farm do a nightly build with a C++ compiler
merely as a test to verify that no C++ compilation errors
are introduced, but continue to use C 'officially' for
builds and releases; or
This was the intent of my suggestion.
There can be
Tom Lane wrote:
Kurt Harriman harri...@acm.org writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
Yours is the first comment anyone has posted
Kurt Harriman harri...@acm.org writes:
However, probably an easier alternative would be to have
just one buildfarm machine do a nightly build configured
with the --enable-cplusplus option.
There is no such option, and won't be.
This would build one file - main.c - as C++ (necessary
because
Is there anything in the source that would necessarily preclude using the
C++ compiler to build *all* the code?
No. Most of the source files would need a sprinkling of
tiny changes: typically only a handful of casts need to be
added. Some files would need more widespread (but still
trivial)
Kurt Harriman harri...@acm.org writes:
Suppose we were to use the C++ compiler to build all of
PostgreSQL. Consider the alternatives: either
A) switch over entirely to C++, no longer supporting C; or
B) let the build farm do a nightly build with a C++ compiler
merely as a test
I wrote:
The stumbling block, though, remains the same as I mentioned in the
message you linked to: if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty.
Actually,
Tom Lane wrote:
Given the above constraints, I think the only real role for C++ here
would be to allow access to third-party C++ libraries as Postgres
extensions --- for instance something like an XML or numerical analysis
I seem to recall that we're already able to do this.
IIRC, some older
Tom Lane wrote:
if we fix some or all of the headers, what's the
plan for making sure that they stay fixed? Without a C++ buildfarm
member I think the chances of future breakage approach certainty.
Actually, after re-reading the whole earlier thread I see that we did
think of a possible
On Saturday 06 December 2008 22:38:29 James Mansion wrote:
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new
Peter Eisentraut wrote:
On Saturday 06 December 2008 22:38:29 James Mansion wrote:
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that
Andrew Dunstan wrote:
The most serious problem AFAIK is that we use setjmp/longjmp, which I
understand does not play at all nicely with C++ exceptions.
Considering the complexity of the code and how it at times stretches the
C standard to the point of cheating, I think anyone's three-item
Greg Smith wrote:
On Fri, 5 Dec 2008, Robert Treat wrote:
Might I suggest you collect all of these various arguments (both for and
against) and patches into a wiki page on the developers wiki?
I'm getting the feeling this is going to take a while to sort out too.
Page with most of the
Kurt Harriman wrote:
The foremost opposing argument seems to have been that there
should be no attempt to alleviate the existing reserved word
problem without automatic enforcement to guarantee that never
in the future can new occurrences be introduced.
Is there anything in the source that
Kurt Harriman wrote:
Sometimes people would like to call C++ code in the PostgreSQL
backend environment... for example, in user-defined functions,
triggers, access methods. And there is sometimes a need for
C++ code to call back into PostgreSQL's C functions, such as
the SPI interface.
Have
A seriously substantial portion of the diff for this patch all is
supporting trivial renaming, like changing everything that uses:
- TypeName *typename = (TypeName *) cmd-def;
+ TypeName *typeName = (TypeName *) cmd-def;
Is that really necessary? After going through a few
Hi Greg,
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
I'll try resubmitting them separately. The first diff consists
of just the renaming, which is
On Fri, 5 Dec 2008, Greg Smith wrote:
If it is needed, I'd suggest you'd get a warmer reception here submitting two
diffs, one that just did the renaming and a second that actually had the
functional bits in it.
You can just ignore this late night bit of idiocy, or mock me for it as
you see
On Fri, 5 Dec 2008, Kurt Harriman wrote:
Actually I did email this to the list with 4 separate diffs in
4 separate attached files. I don't know why it appears all
massed together at http://archives.postgresql.org/pgsql-hackers.
Thanks for being so attentive. Your e-mail was fine, the
On Friday 05 December 2008 03:55, Peter Eisentraut wrote:
Kurt Harriman wrote:
Sometimes people would like to call C++ code in the PostgreSQL
backend environment... for example, in user-defined functions,
triggers, access methods. And there is sometimes a need for
C++ code to call back
Greg Smith [EMAIL PROTECTED] writes:
You can just ignore this late night bit of idiocy, or mock me for it as you
see
fit. Note to other reviewers: if your e-mail client is the sort that bunches
a series of text attachments all together, make sure to scroll completely past
the first patch
Hi Peter,
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
This series of patches is meant to address some
Kurt Harriman [EMAIL PROTECTED] writes:
Hi Peter,
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
Kurt Harriman wrote:
Have you considered writing a procedural language plugin for C++?
C++ can masquerade as C, so I don't think it needs a separate
plugin. Just tell PostgreSQL that your user-defined function
is C even though you secretly know it is C++.
FYI, we have received patches
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Gregory Stark [EMAIL PROTECTED] writes:
Well one thing that might be useful for a c++ procedural language would be
catching C++ exceptions and translating them into ereports which could then be
caught in Postgres.
That's actually what I thought you had done but I just reread your mail and
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005 in the archives, and found only this thread
covering similar
Tom Lane wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
This has been proposed before, and rejected before, and I don't believe
the arguments have changed in the least.
Hi Tom,
Of the series of four patches, the first two (c++reserved and c++bookends)
On Friday 05 December 2008 10:45, Kurt Harriman wrote:
Tom Lane wrote:
Kurt Harriman [EMAIL PROTECTED] writes:
[ make the backend C++-compilable ]
I tested applying this patch to CVS HEAD today and compiling
with --enable-cplusplus with gcc 4.2:
$ ldd postmaster
...
On Friday 05 December 2008 09:51:50 Kurt Harriman wrote:
Peter Eisentraut wrote:
FYI, we have received patches morally equivalent to yours many times
over the years, and they have all been rejected. You might want to
review the archives about that.
Hi Peter,
I went back as far as 2005
On Fri, 5 Dec 2008, Robert Treat wrote:
Might I suggest you collect all of these various arguments (both for and
against) and patches into a wiki page on the developers wiki?
I'm getting the feeling this is going to take a while to sort out too.
Page with most of the relevant stuff Kurt has
36 matches
Mail list logo
