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
Josh Berkus 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 example, 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 C+
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 GEOS
[ just realized that I set this message aside to reply to later, and
then forgot about it --- apologies ]
Kurt Harriman 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 c++configure patch, and
>>> Kurt Harriman 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 libpoppler.
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 advantag
Tom Lane wrote:
Kurt Harriman 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 to the list
regard
Kurt Harriman 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 on some plat
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 answer
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
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.
Actuall
Kurt Harriman 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 to verify t
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) ch
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 list
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 nev
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
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 would
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
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 p
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 fa
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
...
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)
a
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 te
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 an
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 (pgsql-hackers@postgr
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 mora
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
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
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
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 cal
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 archive
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
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 inten
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 pag
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 yo
36 matches
Mail list logo
