Re: Mostly Harmless: Welcoming our C++ friends
От | Kurt Harriman |
---|---|
Тема | Re: Mostly Harmless: Welcoming our C++ friends |
Дата | |
Msg-id | 49394006.2070103@acm.org обсуждение исходный текст |
Ответ на | Re: Mostly Harmless: Welcoming our C++ friends (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Mostly Harmless: Welcoming our C++ friends
(Robert Treat <xzilla@users.sourceforge.net>)
Re: Mostly Harmless: Welcoming our C++ friends (James Mansion <james@mansionfamily.plus.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: