Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 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) changes, such as renaming local variables or > parameters which are C++ reserved words. There are a few > head-scratchers: see this post (1 July 2007) > http://groups.google.com/group/pgsql.patches/msg/91775dc1355cdc72 > or http://tinyurl.com/6a67ms > > I've actually gone through the tedious experiment of fixing up > about 40 of the source files so they can be compiled as either > C or C++. With these files compiled as C++, and the remainder > compiled as C, PostgreSQL builds successfully and passes the > 'make check' regression tests. The intermixture of C together > with C-compiled-as-C++ works just fine, at least on my x86-32 > Linux platform. On the other hand, PostgreSQL already works > as C; trying to convert it all to C++ doesn't seem useful. > > 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 that no C++ compilation errors > are introduced, but continue to use C 'officially' for > builds and releases; or > >C) support C and C++ equally, allowing the choice to be made > by each person who builds PostgreSQL from source. > > Alternative A breaks (almost?) all existing third party > extension code: sufficient reason to rule out this alternative. > > With Alternative B, most development work would probably still > be done in C. C programmers surely won't embrace the idea > that they should conform to C++ rules and take care that their > C code is C++-compilable. Some of the C++ rules are obscure; > rare is the C++ programmer who never omits a needed cast. > Every patch will have to be checked for C++ compatibility. > If the build farm detects a C++ error, likely one of the > committers would be saddled with the burden of backing > out the patch and/or correcting the error. > > Alternative C seems to just about double the amount of work > involved in every commit, build, and release. Again, much > of the burden probably falls on the committers. > > All the extra work and trouble will be justified if there is > a truly spectacular payoff. What magnificence awaits us when > all of PostgreSQL is C++-compilable? I don't have a good > answer. > > The best alternative, in my opinion, is "none of the above". > 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. > > As a courteous host, one might extend hospitality to a guest, > but not indeed go so far as to redecorate the house from top > to bottom to suit the guest's taste. > > Regards, > ... kurt > > James Mansion wrote: > > Is there anything in the source that would necessarily preclude using the > > C++ compiler to build *all* the code? > > > > I'd guess that this would be quite a big patch to do this in any places > > where we have implicit conversions from void* to char* etc, but > > the result is valid as C and C++ and arguably better documented. > > > > C++ is picky about a few things you can do in C, but most of them > > are things I'd rather not do anyway. > > > > Run such a build on the build farm each night, and it will be obvious as > > soon as C++-unfriendly code sneaks in. > > > > And who know, maybe eventually we could use C++ properly in the > > code. > > > > James > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 > fully OSS implementation of annealing (potentially useful as a > replacement for GEQO) is in C++. Well, if we were actually contemplating using it, we'd rewrite it in C. I don't see anyone around here who's in favor of increasing the minimum build requirement to C++. (Even if we were, there's exactly 0 chance that an existing hunk of C++ code would follow our error handling and memory allocation conventions, so we'd have to do significant rewriting anyway.) The PostGIS-style case, where someone writes some code to provide a mostly arm's-length interface to an external library written in C++, is the only case I can see much use for. And that still leaves me wondering what's the point of making our headers C++ clean, because that external library isn't gonna include 'em anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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++ 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 fully OSS implementation of annealing (potentially useful as a replacement for GEQO) is in C++. However, the real reason to do this is to attract C++ hackers to hack on PostgreSQL and extend it. Most of what makes PostgreSQL cool now we got because PostgreSQL is so easy for C geeks to hack on. Who knows what the C++ crowd will contribute if given the opportunity? It's not the stuff we *know* we can get which is exciting, it's the stuff we don't know about. (and yes, I realize this would hold true of other programming languages as well. However, we can't support them as easily as C++) As the Guy Who Is Obsessed With Making Our Community Grow (GWIOWMOCG), I strongly support this goal. Although the other issues like breakage need fixing. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 library that PostGIS uses (used?): http://postgis.refractions.net/support/wiki/index.php?GEOS "GEOS is a C++ port of the JTS Topology Suite. It is used by PostGIS to implement Topological functions. " However it seems to work fine even without the C++-header project, so I must be missing something here... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
[ 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 it sounds > alarmingly definite. > May I ask you to elaborate? Have you more to say on the > subject? Well, as I understand it the proposal is to build main.c as C++ in the hope of (1) identifying C++ incompatibilities in our include headers, and (2) linking C++ instead of C library on platforms where they are different. As for #1, main.c doesn't (and shouldn't) include a large fraction of the headers that might be interesting to a C++ add-on --- I'm surprised that it hits as many as it does, because it surely has no direct use for most of them. > Extra #includes could be added to main.c just for the purpose of > getting them C++-syntax-checked. They'd disappear again the next time Bruce runs his unnecessary-#include elimination script. And anyway the vast majority of the inclusions you show here are accidental, indirect inclusions that might go away in any header refactoring. As for #2, thanks but no thanks: the very last thing I want is to have a switch that causes us to start running on a different basic C library. That would open all sorts of portability and testability concerns. AFAIK there are only a few obsolete platforms where a C++-specific libc is needed, and I'm perfectly happy to blow off the idea of supporting C++ add-ons on them. So I'm willing to support a project of making *all* our headers (or at least all the ones a C++ addon could possibly care about) C++-safe, if there's buildfarm support for making sure they stay that way. But I don't approve of changing the way main.c gets compiled. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
>>> 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. It didn't seem very hard to do without any of this. Granted, it isn't likely to be portable to all environments, which is why we haven't bothered to try to put it out for the community; but there didn't seem to be any great barriers for our environment (SuSE/gcc). Is this intended to make such efforts more portable, so they can be shared with more environments? Did we just get lucky? -Kevin P.S. Our environment: PostgreSQL 8.3.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070115 (SUSE Linux) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 advantages in that you can use a lot of C99 (and still port to non-C99 envs eg MSVC) if you have a few ifdefs to use std::vector instead of dynamic arrays, but the bigger issue (for me) was always been that the name mangling means that you find out pretty quickly if you have a mismatch between declaration and definition of functions. Attempting the link with C++ mangling can put this to rest, even if you never try running it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 regarding my proposed c++configure patch, and it sounds alarmingly definite. May I ask you to elaborate? Have you more to say on the subject? This would build one file - main.c - as C++ (necessary because on some platforms the main() function needs to be C++ to ensure the C++ runtime library is initialized). Useless, since main.c doesn't include any large number of headers, main.c directly or indirectly includes these 71 headers: access/attnum.h access/genam.h access/heapam.h access/htup.h access/rmgr.h access/sdir.h access/skey.h access/tupdesc.haccess/tupmacs.h access/xlog.h access/xlogdefs.h bootstrap/bootstrap.h c.h catalog/genbki.hcatalog/pg_am.h catalog/pg_attribute.h catalog/pg_class.h catalog/pg_index.h executor/execdesc.h executor/tuptable.h fmgr.h lib/stringinfo.hnodes/bitmapset.h nodes/execnodes.h nodes/nodes.h nodes/params.h nodes/parsenodes.h nodes/pg_list.h nodes/plannodes.h nodes/primnodes.h nodes/tidbitmap.h nodes/value.h pg_config.h pg_config_manual.h pg_config_os.h pgtime.h port.h postgres.h postgres_ext.h postmaster/postmaster.h rewrite/prs2lock.h storage/backendid.h storage/block.h storage/buf.h storage/bufpage.h storage/item.h storage/itemid.hstorage/itemptr.h storage/lock.h storage/lwlock.hstorage/off.h storage/relfilenode.h storage/shmem.h tcop/dest.h tcop/tcopprot.h utils/array.h utils/elog.h utils/errcodes.hutils/guc.h utils/help_config.h utils/hsearch.h utils/int8.hutils/palloc.h utils/pg_crc.h utils/pg_locale.h utils/ps_status.h utils/rel.h utils/relcache.hutils/snapshot.h utils/timestamp.h utils/tuplestore.h and in particular there is no reason for it to include the headers that are critical to function libraries. Extra #includes could be added to main.c just for the purpose of getting them C++-syntax-checked. Or, a few more .c files could be chosen to expand the set of C++-syntax-checked headers. For instance, xml.c pulls in spi.h and 96 other headers. 66 of them overlap with main.c; but these 31 are new: access/xact.h catalog/namespace.h catalog/pg_language.h catalog/pg_proc.h catalog/pg_type.h commands/dbcommands.h executor/execdefs.h executor/executor.h executor/spi.h lib/dllist.hlibpq/pqformat.hmb/pg_wchar.h miscadmin.h nodes/memnodes.hnodes/nodeFuncs.h nodes/relation.htcop/pquery.h tcop/utility.h utils/builtins.hutils/catcache.hutils/date.h utils/datetime.hutils/datum.h utils/lsyscache.h utils/memutils.hutils/plancache.h utils/portal.h utils/resowner.hutils/syscache.hutils/tzparser.h utils/xml.h funcapi.h is still missing. One file that includes it is pl_exec.c, which pulls in 8 more headers not already listed: access/transam.hcommands/trigger.h executor/spi_priv.h funcapi.h parser/scansup.hplpgsql.h utils/snapmgr.h utils/typcache.h So C++-compiling just a few source files is sufficient to syntax check a useful subset of header files including those which are most important for add-on development. However, the above approach has a couple of obvious caveats: :( It doesn't give C++ users a precise specification of exactly which header files they may rely upon from release to release. :( From time to time, C++ programmers will probably come along asking for even more header files to be sanitized. The alternative which you have suggested, using pgcompinclude, could solve these caveats by enforcing C++ safety upon every PostgreSQL header file. And it would not require any more .c files beyond main.c to be kept C++-clean. http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php I'll get started on the pgcompinclude thing. Regards, ... kurt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 platforms the main() function needs to be > C++ to ensure the C++ runtime library is initialized). Useless, since main.c doesn't include any large number of headers, and in particular there is no reason for it to include the headers that are critical to function libraries. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 to that: http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php which in fact is on the TODO list now. So if someone wanted to step up and make that happen, it would become sane to try to have C++-clean headers. I'd be happy to work on that. However, probably an easier alternative would be to have just one buildfarm machine do a nightly build configured with the --enable-cplusplus option. This would build one file - main.c - as C++ (necessary because on some platforms the main() function needs to be C++ to ensure the C++ runtime library is initialized). The C++ compilation of main.c will fail if any C++ reserved words have been used as identifiers in the headers included there. main.c already pulls in most of the headers which are of interest for calling back in to postgres (see attached .svg file). To complete the set, I could add #include's for funcapi.h and spi.h. C++-clean headers should be far less burdensome than trying to keep the whole codebase C++-clean, because it is not very often that someone would inadvertently choose a C++ reserved word to use as a new field name or identifier in one of these .h files; and main.c is not often changed. (One of my patches - c++exception - adds a second file to be C++ compiled (postgres.c). I'm planning to revise that patch so that only main.c gets C++ compiled, to reduce the exposure to inadvertent breakage of the --enable-cplusplus build.) Would it be worthwhile to make all the headers C++-clean, rather than just the ones which seem likely to be pulled in by a new access method, data type, or programming language? The pgcompinclude proposal would be attractive if every header file needs to be checked. (My opinion: do that only if somebody needs it.) Regards, ... kurt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 postgis's wrapped some C++ library that they used internally; and some of my old scripts for installing postgres have: "env LDFLAGS=-lstdc++ ./configure --prefix=$PGHOME" I guess existing current c++ postgres extensions probably have a C wrapper? and I guess the main benefit of this project would be that the C wrapper could be thinner (or even nonexistant?) with these proposed changes? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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, after re-reading the whole earlier thread I see that we did think of a possible answer to that: http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php which in fact is on the TODO list now. So if someone wanted to step up and make that happen, it would become sane to try to have C++-clean headers. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 that no C++ compilation errors > are introduced, but continue to use C 'officially' for > builds and releases; or >C) support C and C++ equally, allowing the choice to be made > by each person who builds PostgreSQL from source. > Alternative A breaks (almost?) all existing third party > extension code: sufficient reason to rule out this alternative. This project isn't even willing to require that people use a C99 compiler ... you won't get far suggesting that the minimum tool be upped to C++. > With Alternative B, most development work would probably still > be done in C. s/most/all/, at least for anything that has ambitions of getting into the core distribution. You can't code in C++ if it needs to be C-compilable. For the same reason, I don't think alternative C is materially different from alternative B: either way the rule is "Write C that doesn't give a C++ compiler indigestion". > All the extra work and trouble will be justified if there is > a truly spectacular payoff. What magnificence awaits us when > all of PostgreSQL is C++-compilable? I don't have a good > answer. 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 library. Now by definition such libraries aren't trying to call into any core Postgres code, so it doesn't seem like converting all the headers to be C++-safe is really an especially useful goal anyhow. There's a subset of headers, like fmgr.h and funcapi.h, that would be needed by the interface layer for such a project, and maybe they should be made C++-clean. 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. So it seems like we have a very high initial investment to obtain something that is really of unclear value. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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) changes, such as renaming local variables or parameters which are C++ reserved words. There are a few head-scratchers: see this post (1 July 2007) http://groups.google.com/group/pgsql.patches/msg/91775dc1355cdc72 or http://tinyurl.com/6a67ms I've actually gone through the tedious experiment of fixing up about 40 of the source files so they can be compiled as either C or C++. With these files compiled as C++, and the remainder compiled as C, PostgreSQL builds successfully and passes the 'make check' regression tests. The intermixture of C together with C-compiled-as-C++ works just fine, at least on my x86-32 Linux platform. On the other hand, PostgreSQL already works as C; trying to convert it all to C++ doesn't seem useful. 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 that no C++ compilation errors are introduced, but continue to use C 'officially' for builds and releases; or C) support C and C++ equally, allowing the choice to be made by each person who builds PostgreSQL from source. Alternative A breaks (almost?) all existing third party extension code: sufficient reason to rule out this alternative. With Alternative B, most development work would probably still be done in C. C programmers surely won't embrace the idea that they should conform to C++ rules and take care that their C code is C++-compilable. Some of the C++ rules are obscure; rare is the C++ programmer who never omits a needed cast. Every patch will have to be checked for C++ compatibility. If the build farm detects a C++ error, likely one of the committers would be saddled with the burden of backing out the patch and/or correcting the error. Alternative C seems to just about double the amount of work involved in every commit, build, and release. Again, much of the burden probably falls on the committers. All the extra work and trouble will be justified if there is a truly spectacular payoff. What magnificence awaits us when all of PostgreSQL is C++-compilable? I don't have a good answer. The best alternative, in my opinion, is "none of the above". 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. As a courteous host, one might extend hospitality to a guest, but not indeed go so far as to redecorate the house from top to bottom to suit the guest's taste. Regards, ... kurt James Mansion wrote: Is there anything in the source that would necessarily preclude using the C++ compiler to build *all* the code? I'd guess that this would be quite a big patch to do this in any places where we have implicit conversions from void* to char* etc, but the result is valid as C and C++ and arguably better documented. C++ is picky about a few things you can do in C, but most of them are things I'd rather not do anyway. Run such a build on the build farm each night, and it will be obvious as soon as C++-unfriendly code sneaks in. And who know, maybe eventually we could use C++ properly in the code. James -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 of major problems is going to be much too short. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 never in the future can new occurrences be introduced. Is there anything in the source that would necessarily preclude using the C++ compiler to build *all* the code? Probably lots, but that's not the problem we are trying to solve here. And many people are seriously not interested in using C++ for PostgreSQL. The most serious problem AFAIK is that we use setjmp/longjmp, which I understand does not play at all nicely with C++ exceptions. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 occurrences be introduced. > > Is there anything in the source that would necessarily preclude using the > C++ compiler to build *all* the code? Probably lots, but that's not the problem we are trying to solve here. And many people are seriously not interested in using C++ for PostgreSQL. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 necessarily preclude using the C++ compiler to build *all* the code? I'd guess that this would be quite a big patch to do this in any places where we have implicit conversions from void* to char* etc, but the result is valid as C and C++ and arguably better documented. C++ is picky about a few things you can do in C, but most of them are things I'd rather not do anyway. Run such a build on the build farm each night, and it will be obvious as soon as C++-unfriendly code sneaks in. And who know, maybe eventually we could use C++ properly in the code. James -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 relevant stuff Kurt has posted so far is now listed > under Development Projects on the wiki: > http://wiki.postgresql.org/wiki/C%2B%2B_Compatibility Is this a TODO? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 posted so far is now listed under Development Projects on the wiki: http://wiki.postgresql.org/wiki/C%2B%2B_Compatibility -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 in the archives, and found only this thread > covering similar territory: > > 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. > > But can we not separate the two problems of (1) actual identifiers > which prevent C++ compilation today, vs. (2) hypothetical code which > someone might submit in the future? The first problem is immediate; > the second would only be troublesome if the hypothetical identifier > makes it all the way through beta testing into a release. > Actually, given your configure changes, istm a buildfarm member compiling with --enablecplusplus would prevent any such issue from getting to far. > > PS. A few other threads had (at least somewhat) relevant discussion. > They're listed below. I didn't find any other patches. I'd appreciate > any links or pointers to any other threads which I should look at. > Might I suggest you collect all of these various arguments (both for and against) and patches into a wiki page on the developers wiki? Also, I've no real experience in masquerading c++ as c, but the main concern I would have is possible imcompatabilities that might be introduced between postgresql's compiled with c++ and those compiled in c. I'm not sure there should be any, but maybe someone with more experience in this area might have ideas on what to watch out for? -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 ... libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7bf9000) ... Then I ran pgbench and played with a table with a UUID column. Performance was great. (I first mistakenly applied it against a not-up-to-date source-tree --- something from mid-September --- and that ended up not compiling.) I still have not tried this with my own C++ code, but it seems to have less impact on the build process than some might have feared. -- David Lee Lambert ... Software Developer Cell phone: +1 586-873-8813 ; alt. email <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> GPG key at http://www.lmert.com/keyring.txt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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) appear much the same as Jacob Rief's patch submitted in June 2007. http://tinyurl.com/6bjcdq (Incidentally, I only just now found that thread. I hadn't seen it earlier because I hadn't searched the now-defunct pgsql-patches list.) The third patch (c++configure) addresses a problem which I have not seen discussed before: There needs to be a portable way to compile and link C++ code. As it stands, the third patch depends upon the first two, because the third one can optionally compile main.c as C++. Since main.c includes some header files in which C++ reserved words are used as identifiers, it cannot be compiled as C++ without fixing at least a subset of those identifiers. However, if it is decided that the identifiers cannot be changed, then I could revise the c++configure and c++exception patches to remove the dependency. Of course it can be expected that, once or twice a year, some starry-eyed newcomer will repeat the plea for the reserved words to be fixed, until you succumb or add it to the FAQ. If a C++ programmer needs ereport(ERROR)s to be recast as C++ exceptions, I propose they can handle that in their own code without special provisions being made in PostgreSQL code. Therefore, I claim it does not need to be addressed in this series of patches. It is a separate issue. However, PostgreSQL code should provide a last-resort exception handler as a backstop against C++ programming errors. That is the purpose of the fourth patch (c++exception). C++ programmers should catch their own exceptions, but if they let one get away, PostgresMain should try to make sure the shared segment isn't left in a corrupt state. In other words, PostgresMain's defense against uncaught C++ exceptions should be approximately equivalent to its existing defense against SIGSEGVs, null pointer dereferencing errors, and similar faults in C. Regards, ... kurt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 territory: * SPI-header-files safe for C++-compiler http://groups.google.com/group/pgsql.patches/browse_frm/thread/6dab9a8134cce102/3c91e40a9e615362?lnk=gst&q=rejected+c%2B%2B#3c91e40a9e615362 or http://tinyurl.com/6bjcdq June 2007 That patch appears approximately equivalent to the first two of my patches, c++reserved and c++bookends. The opposing arguments in that thread seem strained, in my opinion, conveying more heat than light. "Hey you kids, get off my lawn!" The conclusion of the deliberative process wasn't set down in that thread; but evidently the arguments in favor were not sufficiently persuasive: in the end, the patch was not applied. 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. But can we not separate the two problems of (1) actual identifiers which prevent C++ compilation today, vs. (2) hypothetical code which someone might submit in the future? The first problem is immediate; the second would only be troublesome if the hypothetical identifier makes it all the way through beta testing into a release. Post #21 in the thread, by Tom Lane on July 4 2007 at 8:05 am, suggests an automated check for non-C++-compilable header files, and highlights the practical difficulties caused by lack of C++ support in the build system. To invoke the C++ compiler at present, typically one would use a hard-wired compiler name with hard-wired flags and paths. My third patch - c++configure - begins to address the need for a portable way to build C++ code, compatible with the way we build C code. The notion of converting all of PostgreSQL to C++ was touched upon. Little would be gained, at the cost of much tedium, so I advise against it. I wouldn't want to redo the old stuff unless there's a clear benefit. My proposal aims to make C++ a practical choice for adding *new* things to PostgreSQL. A topic of great interest is the relationship between C++ exceptions and the PostgreSQL backend's error handling based on setjmp/longjmp. My fourth patch - c++exception - adds a backstop to limit the damage in case a C++ exception is thrown from anywhere in the backend and not caught. The patch converts an uncaught exception to a PostgreSQL FATAL error, so the process can clean itself up and report its failure rather than just silently disappearing. If C++ code doesn't catch its exceptions, that is a programming error, similar to a segment violation or null pointer dereference, and worthy of termination. These four patches aren't meant to create a palace of luxury for C++ programmers. More could be done: more sophisticated error handling could be provided; new/delete could be hooked up to palloc/pfree; templates and class libraries could be written. But C++ programmers can do these things for themselves, if we give them a fighting chance: just take away the roadblocks (primarily the reserved words) and make it easy to compile and link. Regards, ... kurt PS. A few other threads had (at least somewhat) relevant discussion. They're listed below. I didn't find any other patches. I'd appreciate any links or pointers to any other threads which I should look at. * STL problem in stored procedures http://groups.google.com/group/pgsql.general/browse_frm/thread/ee352086139df2bf/400e8133b3e87d74?tvc=1&q=stl+problem+in+stored+procedures#400e8133b3e87d74 http://tinyurl.com/5hhf2v October 2005 * C++ -> C : Module for converting the WHERE clause to the canonical form with PostgreSQL http://groups.google.com/group/pgsql.hackers/browse_frm/thread/6cb99c3521318653/d6f2b9509cda35c5?lnk=gst&q=tom+lane+c%2B%2B#d6f2b9509cda35c5 or http://tinyurl.com/6atqmq January 2006 * PG Extensions: Must be statically linked? http://groups.google.com/group/pgsql.hackers/browse_frm/thread/89d3650c52430186/c63c94680b399827?lnk=gst&q=pg+extensions+must+be+statically+linked#c63c94680b399827 or http://tinyurl.com/6q5jdz March 2006 * Writing triggers in C++ http://groups.google.com/group/pgsql.hackers/browse_frm/thread/2a95d656b8add4dd/ded7ff4ce06ae456?lnk=gst&q=writing+triggers+in+c%2B%2B#ded7ff4ce06ae456 or http://tinyurl.com/6kx8ba February 2007 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 > realized you only handled unhandled exceptions which cause the backend to die. Well, that's too bad, because fixing the error-handling impedance mismatch is the one thing that's been missing from every previous proposal, and it's the one thing that might actually make C++ in the backend useful rather than a toy. It's possible/likely that this would be easier to do in the context of a PL; that would at least provide a single point at which to catch C++ exceptions and turn them into elogs. The hard part is turning elogs into exceptions so that errors thrown by core backend functions that're called by the C++ code will behave as a C++ programmer would expect. For comparison look at the way that errors are handled in pl/perl etc. The relatively narrow "SPI" API for calling back into the main backend makes it somewhat sane to convert elogs into Perl errors, though it's less efficient than one could wish. I don't know how to scale that solution up to the point where you could call any random internal backend function, as Kurt seems to be hoping for. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 morally equivalent to yours many times over the years, and they have all been rejected. You might want to review the archives about that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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++. 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 realized you only handled unhandled exceptions which cause the backend to die. The other way around could be useful too -- catching ereports/elogs within a backend API call from C++ code and throwing a C++ exception. I'm not sure if that's doable though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 of the mechanics of getting C++ code compiled and linked for the PostgreSQL backend environment. At present the build system has no support for languages other than C. To interface PostgreSQL to a C++ tool or library, it's necessary to either hack the PostgreSQL build system, or bypass it and set up your own build system. Either alternative is likely to be non-portable and difficult for others to understand or use. This presents a serious obstacle to contributing the code to the PostgreSQL community or sharing it with others. Because C++ is so similar to C, the PostgreSQL build system can easily provide equal support to both languages. C++ users can then integrate their code easily and portably, and others can share the code with no need to wrestle with jury-rigged makefiles. Nobody should have to figure out autoconf, m4, and gmake unless they want to. The 'c++configure' patch therefore addresses the necessity to find the host platform's C++ compiler; invoke it with appropriate options; link with the C++ runtime library; and initialize the C++ environment. Another obstacle which would not be addressed by a procedural language plugin is the problem of access to the backend's APIs and data structures. C++ can use C declarations directly with no extra wrappers or translation layers such as other languages usually need. However, C++ cannot parse a C header file in which a C++ reserved word is used as an identifier. The 'c++reserved' patch renames some fields in a very few header files so C++ code can interface with the PostgreSQL backend environment to the extent needed for implementing a procedural language, data type, etc. Although tedious, such renaming is by far the most reliable, maintainable and efficient means of exposing the PostgreSQL runtime facilities to C++. As a straightforward renaming, it is a safe change: its completeness and much of its correctness are checked by the C compiler. > PostgreSQL supports a lot of extension languages, and none of > them require the amount of backend changes that you outline here, > because the PL plugin serves as glue. C++ doesn't need glue like those other languages, but it does need just a little help so that it can be used for the same kinds of jobs that C is used for. Those other extension languages, such as plpgsql or plpython, serve a different audience than C or C++. They offer quick development, ease of use, and high-level expressiveness where performance is not the primary concern. C or C++ are chosen when high performance is needed with precise control over data representation and the ability to interoperate directly with almost any language / library / system call / network protocol / etc - notably, PostgreSQL's own tree structures and data types. Thanks for your comments; I hope I've responded adequately. In any case, I welcome further dialogue on these or other topics. Regards, ... kurt 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 into PostgreSQL's C functions, such as the SPI interface. Have you considered writing a procedural language plugin for C++? PostgreSQL supports a lot of extension languages, and none of them require the amount of backend changes that you outline here, because the PL plugin serves as glue. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 in the diff before you pay attention to the rest of it. I'm > going to bed. Your email client is doing the right thing. The attachments had the following header on them which controls this: Content-Disposition: inline; I wonder how many email clients let the poster control this header though :( If you post with content-disposition set to "attachment" instead of "inline" it should appear as a separate file you can save. Regarding the patches, we could apply the trivial stuff right around the time of the pgindent run, after all the major patches are drained from the queue so it doesn't cause extra conflicts. It would still cause any other pending patches for 8.5 to bitrot but from the sounds of things shouldn't be too hard to fix up. It seems to me we ought to do this regardless of whether we apply the functional changes. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 into PostgreSQL's C functions, such as > > the SPI interface. > > Have you considered writing a procedural language plugin for C++? > PostgreSQL supports a lot of extension languages, and none of them > require the amount of backend changes that you outline here, because the > PL plugin serves as glue. I think this patch is great, although I haven't had time to test it yet. The only real "backend change" is the exception-handling clause; and the fact that the backend will also be linked against the C++ runtime library. Everything else is routine stuff that an experienced C++ developer would end up catching while trying to get his build-system for a new project running; but it could certainly scare away someone with less experience. Better to deal with this way ahead of time and test it on a few platforms. -- David Lee Lambert ... Software Developer Cell phone: +1 586-873-8813 ; alt. email <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> GPG key at http://www.lmert.com/keyring.txt pgp3zsixMgumQ.pgp Description: PGP signature
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 archives just mash multiple text-based attachments tagged as Text/PLAIN together like that, as does my mail reader. 1522 lines of only renaming in part 1, no wonder I gave up. I see you've already started re-sending the individual parts as separate messages; that's nice for initial casual browsing of them, but will get boring for everybody if you do that every time. If you've got more than one text file to attach, for future updates you might consider a tar archive of them to keep them running together in the archives. Once you're putting stuff into an archive, might as well compress it too, particularly for a patch of this size. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 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 in the diff before you pay attention to the rest of it. I'm going to bed. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 intentionally trivial and boring.
The second diff adds a few extern "C" {...} declarations - also
trivial and boring, but small. The interesting part is in the
third diff.
Regards,
... kurt
Greg Smith wrote:
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 pages of diff code
where supporting this trivial bit was the only change, my eyes glazed
over. Minimizing diff size makes it much more likely somebody will
complete a review of the functional parts of your submission before
getting bored.
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. Then it would be possible to
casually scan the renaming one for a second to see it was trivial and
boring, followed by a review of the functional one that was focused on
its real changes.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 pages of diff code where supporting this trivial bit was the only change, my eyes glazed over. Minimizing diff size makes it much more likely somebody will complete a review of the functional parts of your submission before getting bored. 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. Then it would be possible to casually scan the renaming one for a second to see it was trivial and boring, followed by a review of the functional one that was focused on its real changes. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mostly Harmless: Welcoming our C++ friends
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 you considered writing a procedural language plugin for C++? PostgreSQL supports a lot of extension languages, and none of them require the amount of backend changes that you outline here, because the PL plugin serves as glue. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
