Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ba1g6-0005Zk-69 for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Aug 2016 14:18:46 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ba1g5-0005uL-E5 for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Aug 2016 14:18:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ba1Vc-0005Lf-PC for pgsql-hackers@postgresql.org; Wed, 17 Aug 2016 14:07:56 +0000 Received: from mail-pa0-x232.google.com ([2607:f8b0:400e:c03::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ba1VY-0007fB-2h for pgsql-hackers@postgresql.org; Wed, 17 Aug 2016 14:07:55 +0000 Received: by mail-pa0-x232.google.com with SMTP id pp5so36778473pac.3 for ; Wed, 17 Aug 2016 07:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LJQdw98rBLAFeMGbMiFzFI3fU12swcxS8IV7g3L4j5w=; b=QZL/sA4tDZVC7LhmzWi/6VF18CYOtWOnx7ngN3J5i9xODxSRChiOF/h6+e3zyVFU1f dQGwez610skqBEmDJVs6gr3gjq8qXfbwwjRdgXeHU+TPMvx0rjSAWUbziacFxCUirFoh GQUOTD7QFqpYLNDC816P9cOxK+6gYjHCVdrpCu3ZkXjijt0gyBa9XoPMrT6fGc0l11kd ZiHDIOuAzjM1JHjYWJ6F/HghwUF1G/t0aqvs1W2nbsUsHJEVjuyYML5JQDaTSN2WTeqM oA3M1j4/t2yffC9eos/yHpvfBqwY+dUNN7YpaeCoSX9wBGIFsy6tdw9ywVKusd1xh1S+ s8Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LJQdw98rBLAFeMGbMiFzFI3fU12swcxS8IV7g3L4j5w=; b=bnLV4xsCae/gBvXij8bRFsqaWSNIjZikd5P8BirBqGtP1KhLgUbh4m16J2fRzqNnuG Wu+5INT6gjSTCjeJ0knTUMFP9FdLF30gvvHtIS34UneteVfZ9ArNaDGqPr9O/0T4Cwqm DpNn34Jwxi27W0yQujhPJiYqIiaoTjUhVYAXpefjnlq7TKI2NIIUDdp0mgjS7umQjx1n 2kozKBJG6vrd0MBd8Hq8S0g3u4ddsk9yuh+s1UhMUOoA4AxuTuAMNz9SrOfD2oLjUVUf QvN32FDlUxK+L7Cr38p9xB+RbSSrzK/5tF5qN1BL35hAomEwrKiuDHPJi+QjIQxtZHA5 H+Aw== X-Gm-Message-State: AEkoout/dIdFXSMS+PoDK3vgi9ASM+8wS07yhvsyzr9CczXiuaesJY/f30/ZWIaSYvuMrw== X-Received: by 10.66.20.166 with SMTP id o6mr74658259pae.96.1471442869301; Wed, 17 Aug 2016 07:07:49 -0700 (PDT) Received: from srielau-ltm.internal.salesforce.com ([204.14.239.106]) by smtp.gmail.com with ESMTPSA id u1sm47675390pfu.12.2016.08.17.07.07.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 07:07:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B35C1A59-4D70-48BE-A45A-2800A7DE51CE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [GENERAL] C++ port of Postgres From: Serge Rielau In-Reply-To: Date: Wed, 17 Aug 2016 07:07:49 -0700 Cc: Andres Freund , dandl , Tom Lane , Pg Hackers Message-Id: References: <007001d1f786$d903fa90$8b0befb0$@andl.org> <00a52208-3199-5858-8846-2530b0bb34df@archidevsys.co.nz> <27271.1471366764@sss.pgh.pa.us> <002401d1f820$a616f7a0$f244e6e0$@andl.org> <20160817005422.qjw7xvnbsbihqykv@alap3.anarazel.de> <003701d1f829$d2308dc0$7691a940$@andl.org> <20160817014944.hkfd46ipmj4rh76y@alap3.anarazel.de> To: Craig Ringer X-Mailer: Apple Mail (2.3124) X-Pg-Spam-Score: -2.7 (--) 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 --Apple-Mail=_B35C1A59-4D70-48BE-A45A-2800A7DE51CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 16, 2016, at 10:16 PM, Craig Ringer = wrote: >=20 > On 17 August 2016 at 09:49, Andres Freund > wrote: > =20 >=20 > You need to include the files surrounded by extern "C" { }. >=20 > I'd really like to adopt the convention used by many libraries etc of = doing this automatically - detecting a c++ compiler in the preprocessor = and wrapping in "extern "C"" . >=20 > Having the codebase c++-clean enough to compile with a c++ compiler = seems to be the easiest way to maintain that, but means more "extern = "C"" droppings in the .c files, not just the headers. Still, pretty = ignoreable. >=20 Big +1 here, Just having community code compilable with a C++ compiler out of the box = would go a long way. Beyond that, on my end I have been working with PG now for a year and a = half and here is a quick list of what I sorely miss from my C++ days: * Overloading of functions (same as in SQL) keeps naming clean * Named parameters (same as SQL) keeps code readable * Adding new function parameters with defaults so I don=E2=80=99t need = to pass in NULL, 0, =E2=80=A6 at 20 places (again supported in SQL) * Member functions greatly help organize code * simple inheritance (as emulated today in node types) At my old employer we used C++ for the DBMS in various degrees in = different components. That degree was agreed upon in coding standards, so we could pick what = we like about C++ and blacklist what we didn=E2=80=99t. E.g. C style exception handling was prohibited Default memory management (new) was prohibited. Instead new() was overloaded and hooked into the DBMS memory manager. I see no reason why this couldn=E2=80=99t be done in PG. I can=E2=80=99t comment of compiling on a Rasperry PI, but know that my = former DBMS code compiled and ran on Windows, Linux, AIX, Sun, HP, and = Mac. But again, just having the community code compile so proprietary (for = now) enhancements could be written in C++ would be huge. Cheers Serge =20= --Apple-Mail=_B35C1A59-4D70-48BE-A45A-2800A7DE51CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 16, 2016, at 10:16 PM, Craig Ringer <craig@2ndquadrant.com> wrote:

On 17 = August 2016 at 09:49, Andres Freund <andres@anarazel.de> wrote:
 

You need to include the files surrounded by extern "C" { }.

I'd really like to adopt the convention = used by many libraries etc of doing this automatically - detecting a c++ = compiler in the preprocessor and wrapping in "extern "C"" .

Having the codebase = c++-clean enough to compile with a c++ compiler seems to be the easiest = way to maintain that, but means more "extern "C"" droppings in the .c = files, not just the headers. Still, pretty ignoreable.

Big +1 here,
Just having = community code compilable with a C++ compiler out of the box would go a = long way.

Beyond = that, on my end I have been working with PG now for a year and a half = and here is a quick list of what I sorely miss from my C++ = days:
* Overloading of functions (same as in SQL) = keeps naming clean
* Named parameters (same as SQL) = keeps code readable
* Adding new function = parameters with defaults so I don=E2=80=99t need to pass in NULL, 0, =E2=80= =A6 at 20 places (again supported in SQL)
* Member = functions greatly help organize code
* simple = inheritance (as emulated today in node types)

At my old employer we used C++ for the = DBMS in various degrees in different components.
That= degree was agreed upon in coding standards, so we could pick what we = like about C++ and blacklist what we didn=E2=80=99t.
E.g. C style exception handling was prohibited
Default memory management (new) was prohibited.
Instead new() was overloaded and hooked into the DBMS memory = manager.
I see no reason why this couldn=E2=80=99t = be done in PG.

I= can=E2=80=99t comment of compiling on a Rasperry PI, but know that my = former DBMS code compiled and ran on Windows, Linux, AIX, Sun, HP, and = Mac.

But = again, just having the community code compile so proprietary (for now) = enhancements could be written in C++ would be huge.


Cheers
Serge
  
= --Apple-Mail=_B35C1A59-4D70-48BE-A45A-2800A7DE51CE--