Re: [GENERAL] C++ port of Postgres

From: Christian Convey <christian(dot)convey(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] C++ port of Postgres
Date: 2016-09-11 16:34:47
Message-ID: CAPfS4ZwqQ_ZvRq1ttXMZcp7sVyBH3wcUcMYv7-HvaB=Ut4h43g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Some of your patches look useful, but unrelated to C++: 7, 8, 15, 16(?), 20.

I applied that subset to 9.6 and got a clean "make check".

Would it make sense to add them to the next commitfest, regardless of
the C++ effort?

On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> [trimmed cc list because of big attachments]
>
> On 8/16/16 4:22 PM, Jim Nasby wrote:
>> Joy, do you have an idea what a *minimally invasive* patch for C++
>> support would look like? That's certainly the first step here.
>
> I developed a minimally invasive patch for C++ support a few years ago
> shortly after I wrote that blog post. Since there appears to have been
> some interest here now, I have updated that and split it up into logical
> chunks.
>
> So here you go.
>
> To build this, you need to configure with g++ <= version 5. (4.x works,
> too.) g++ version 6 does not work yet because of the issues described
> in patch 0013.
>
> Then you also need to edit src/Makefile.custom and set
>
> COPT = -fpermissive -Wno-sign-compare -Wno-write-strings
>
> The -W options are optional just to reduce some noise. Cleaning up
> those warnings can be a separate project that might also have some
> benefit under C.
>
> The -fpermissive option is a g++ specific option that reduces some
> errors to warnings. (So this won't work with clang or other compilers
> at all at this point.) In particular, C++ does not allow casting from
> or to void pointers without a cast, but -fpermissive allows that. The
> step from this to "real" C++ would be adding a bunch of casts around
> things like malloc and palloc and other places. That would be mostly
> busy work, so I have excluded that here.
>
> The patches are numbered approximately in increasing order of dubiosity.
> So 0001 is probably a straight bug fix, 0002 and 0003 are arguably
> minor bug fixes as well. The patches through 0012 can probably be
> considered for committing in some form. After that it gets a bit hackish.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Patrick B 2016-09-11 23:17:11 large number dead tup - Postgres 9.5
Previous Message Tom Lane 2016-09-11 14:32:04 Re: Duplicate data despite unique constraint

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-09-11 16:47:52 Re: Useless dependency assumption libxml2 -> libxslt in MSVC scripts
Previous Message Tom Lane 2016-09-11 16:20:32 Re: Merge Join with an Index Optimization