Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bZhis-0006iZ-Gt for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Aug 2016 17:00:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bZhis-0001bv-3b for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Aug 2016 17:00:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bZhiq-0001Xv-Oa for pgsql-hackers@postgresql.org; Tue, 16 Aug 2016 17:00:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bZhin-0007Lu-Vt for pgsql-hackers@postgresql.org; Tue, 16 Aug 2016 17:00:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u7GGxOvZ027272; Tue, 16 Aug 2016 12:59:24 -0400 From: Tom Lane To: Robert Haas cc: Jim Nasby , Gavin Flower , dandl , Adam Brusselback , Joy Arulraj , kang joni , Dmitry Igrishin , Pg Hackers , Peter Eisentraut Subject: Re: [GENERAL] C++ port of Postgres In-reply-to: References: <007001d1f786$d903fa90$8b0befb0$@andl.org> <00a52208-3199-5858-8846-2530b0bb34df@archidevsys.co.nz> Comments: In-reply-to Robert Haas message dated "Tue, 16 Aug 2016 12:33:40 -0400" Date: Tue, 16 Aug 2016 12:59:24 -0400 Message-ID: <27271.1471366764@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > I'm not really interested in supporting PostgreSQL code written in > other languages entirely, such as Rust, but I do think it would make > sense to write our code so that it can be compiled using either a C > compiler or a C++ compiler. Even if we don't ever use any C++ code in > core, this would let people who create forks or extensions use it if > they wished. It wouldn't be that much work to maintain, either: we'd > just set up some buildfarm members that compiled using C++ and when > they turned red, we'd go fix it. I think this might have advantages purely from the standpoint of new compilers possibly offering useful warnings we don't get now. But if we only go this far, I'm pretty dubious that it really helps people to develop extensions in C++. Almost invariably, if you ask *why* they want to do that, you'll get an answer involving C++ libraries that are not going to play very nice with our error handling or memory management conventions. I do not see how we could C++-ify the error handling without making a complete break with C compilers ... which is a step I don't really want to take. The whole thing would make a lot more sense given a credible design for error handling that keeps both languages happy. A lot of the other things people have muttered about, such as heavier use of inline functions instead of macros, don't particularly need C++ at all. 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