Re: [HACKERS] [GENERAL] C++ port of Postgres

On 4/5/17 19:14, Andres Freund wrote: > Hi Peter, > > On 2017-02-28 22:30:16 -0800, Andres Freund wrote: >> On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: >>> On 1/26/17 22:46, Andres Freund wrote: On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > Yeah, I have committed a few

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi Peter, On 2017-02-28 22:30:16 -0800, Andres Freund wrote: > On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: > > On 1/26/17 22:46, Andres Freund wrote: > > > On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > > >> Yeah, I have committed a few of the patches now and I'll close the CF >

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi, On 2017-02-28 23:42:45 -0500, Peter Eisentraut wrote: > On 1/26/17 22:46, Andres Freund wrote: > > On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > >> Yeah, I have committed a few of the patches now and I'll close the CF > >> entry now. Thanks for your research. > > > > Are you planni

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi Peter, On 2016-09-30 15:24:09 -0400, Peter Eisentraut wrote: > Yeah, I have committed a few of the patches now and I'll close the CF > entry now. Thanks for your research. Are you planning to push more of these at some point? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 9/28/16 10:48 PM, Thomas Munro wrote: > I wonder if the following bit of gin.h should be more nuanced: maybe > it's OK to convert between bool and GinTernaryValue, but it's > definitely not OK to cast between pointers types? Or maybe we should > have a function/macro to convert between the type

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 9/6/16 2:58 PM, Heikki Linnakangas wrote: > 0001-0003 look clear to me as well. 0006 - 0009 also seem OK. The rest > really only make sense if we decided to make the switch to C++. I have committed 0001, 0002, 0003, 0006, as well as 0012. Thomas Munro had some interesting comments on 0007-000

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Mon, Sep 26, 2016 at 10:57 AM, Thomas Munro wrote: > On Thu, Sep 1, 2016 at 1:41 AM, Peter Eisentraut > 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 woul

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Thu, Sep 1, 2016 at 1:41 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.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 t

Re: [HACKERS] [GENERAL] C++ port of Postgres

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 wrote: > [trimmed cc li

Re: [HACKERS] [GENERAL] C++ port of Postgres

> P.S. I'm asking because I was planning to review that patch. But I >> can't tell if any more review by a non-committer is still required by >> the commitfest workflow. > > > I think this has gotten enough attention, for the commitfest workflow. The > workflow is flexible, depending on the nature

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 09/11/2016 01:20 AM, Christian Convey wrote: Hi Heikki, Could I ask you a newbie-reviewer question about something I'm seeing here? https://commitfest.postgresql.org/10/776/ From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides), I got the impression that a successful patch w

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 09/11/2016 01:20 AM, Christian Convey wrote: Hi Heikki, Could I ask you a newbie-reviewer question about something I'm seeing here? https://commitfest.postgresql.org/10/776/ From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides), I got the impression that a successful patch w

Re: [HACKERS] [GENERAL] C++ port of Postgres

Christian Convey writes: >If that's correct, then it sounds like the only way Joy's commit has >a chance of acceptance is if Peter's commit is rejected. >Because Peter's commit might be merged as part of the 2016-09 >commitfest, but Joy's can show up until 2016-11 at the earliest.

Re: [HACKERS] [GENERAL] C++ port of Postgres

Hi Heikki, Could I ask you a newbie-reviewer question about something I'm seeing here? https://commitfest.postgresql.org/10/776/ >From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides), I got the impression that a successful patch would always have this sequence of states in commi

Re: [HACKERS] [GENERAL] C++ port of Postgres

> Thanks. It sounds like worst-case scenario, I perform an unneeded > review. I'll give it a shot. Hi guys, Apologies for more boring process-related questions, but any pointers would be greatly appreciated... I'm a bit confused about how PG's code-review process is meant to handle this C++ por

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Sep 6, 2016 at 3:12 PM, Tom Lane wrote: >> (2) It seems like there are still a few big questions about this commit: >>- Is it wanted at the moment? It didn't seem like there's a >> consensus about whether or not this enhancement should be >> merged, even if the patch is pret

Re: [HACKERS] [GENERAL] C++ port of Postgres

Christian Convey writes: > Could someone help me with a few procedural questions? > (1) This page: https://wiki.postgresql.org/wiki/Reviewing_a_Patch > lists the current commitfest's manager as "(vacant)". But this page: > https://commitfest.postgresql.org/ seems to indicate that a commitfest >

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 08/31/2016 04:41 PM, Peter Eisentraut wrote: 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. Lookin

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut 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 b

Re: [HACKERS] [GENERAL] C++ port of Postgres

[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 a

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 18 August 2016 at 02:14, Gavin Flower wrote: > My main language is Java, and there are a lot of very good reasons for > rewriting Postgres in Java, but I'd never push that - as there are also > many good reasons for NOT rewriting Postgres in Java! > I don't know why folks are jumping on the

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 17/08/16 23:40, Aleksander Alekseev wrote: I'm sure this wasn't your intent, but the tone of your response is part of why people don't get involved with Postgres development... Please note that you're the only person in the entire thread that's said anything to the effect of a holy war... OT

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Wed, Aug 17, 2016 at 11:36 AM, Andrew Gierth wrote: >> "Robert" == Robert Haas writes: > > Robert> Hmm, so sizeof() has different semantics in C vs. C++? > > No. '1' has different semantics in C vs C++. (In C, '1' is an int, > whereas in C++ it's a char. It so happens that (sizeof '1') is

Re: [HACKERS] [GENERAL] C++ port of Postgres

> "Robert" == Robert Haas writes: Robert> Hmm, so sizeof() has different semantics in C vs. C++? No. '1' has different semantics in C vs C++. (In C, '1' is an int, whereas in C++ it's a char. It so happens that (sizeof '1') is the only case which is valid in both C and C++ where this makes

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 5:08 PM, Piotr Stefaniak wrote: > On 2016-08-16 18:33, Robert Haas wrote: >> 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 that there exist subtl

Re: [HACKERS] [GENERAL] C++ port of Postgres

2016-08-17 14:40 GMT+03:00 Aleksander Alekseev : >> I'm sure this wasn't your intent, but the tone of your response is >> part of why people don't get involved with Postgres development... >> >> Please note that you're the only person in the entire thread that's >> said anything to the effect of a

Re: [HACKERS] [GENERAL] C++ port of Postgres

> On Aug 16, 2016, at 10:16 PM, Craig Ringer wrote: > > On 17 August 2016 at 09:49, Andres Freund > 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 aut

Re: [HACKERS] [GENERAL] C++ port of Postgres

> I'm sure this wasn't your intent, but the tone of your response is > part of why people don't get involved with Postgres development... > > Please note that you're the only person in the entire thread that's > said anything to the effect of a holy war... > > OTOH, if the community takes the stan

Re: [HACKERS] [GENERAL] C++ port of Postgres

> Two big projects lately move to C++ from C: > GCC, Mesa > > You can read their reasons. > Only C++ we can use without full rewrite currently. (or ObjectC maybe) > If we wish fix C limitations. > I would like just to leave this link here: https://en.wikipedia.org/wiki/List_of_fallacies Long

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 17 August 2016 at 09:49, Andres Freund 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

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-17 11:51:04 +1000, dandl wrote: > > > From my particular perspective it would be enough if all the > > internal > > > headers (that one needs to use in writing server-side extensions) > > were > > > completely usable in C++. > > > > That should already be the case. There's even a dirty

Re: [HACKERS] [GENERAL] C++ port of Postgres

> > From my particular perspective it would be enough if all the > internal > > headers (that one needs to use in writing server-side extensions) > were > > completely usable in C++. > > That should already be the case. There's even a dirty hack^WWscript > that checks that that remains the case >

Re: [HACKERS] [GENERAL] C++ port of Postgres

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan > I think that the best thing about C++ is the ability to encapsulate and > simplify some aspects of resource management quite well, which necessitates > reimplementing PG_TRY/CATCH.

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-17 10:45:25 +1000, dandl wrote: > From my particular perspective it would be enough if all the internal > headers (that one needs to use in writing server-side extensions) were > completely usable in C++. That should already be the case. There's even a dirty hack^WWscript that checks t

Re: [HACKERS] [GENERAL] C++ port of Postgres

> Well, getting so that we can at least compile in both systems would > certainly increase the chances of somebody being willing to work on > such a design. >From my particular perspective it would be enough if all the internal headers >(that one needs to use in writing server-side extensions)

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 4:22 PM, Jim Nasby wrote: > On 8/16/16 12:53 PM, Joy Arulraj wrote: > >> > The whole thing would make a lot more sense given a credible design >> > for error handling that keeps both languages happy. >> >> Well, getting so that we can at least compile in both s

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 16 August 2016 at 17:08, Piotr Stefaniak wrote: > On 2016-08-16 18:33, Robert Haas wrote: >> 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 that there exist subtle dif

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 16:59:56 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: > >> Actually, come to think of it, I guess this is wrong. The problem with > >> what I say here is that longjmp() and setjmp() are incompatible with > >> the stack unwind

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:59 PM, Tom Lane wrote: >> FWIW, IIRC that's not true for gcc/glibc, because they IIRC use common >> codepaths. But obviously that's not all-encompassing enough to rely on that. > > I wonder whether it'd be possible to implement the PG_TRY/CATCH macros > to use C++ excepti

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 18:33, Robert Haas wrote: > 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 that there exist subtle differences between C and C++ that without compile-time diagno

Re: [HACKERS] [GENERAL] C++ port of Postgres

Andres Freund writes: > On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: >> Actually, come to think of it, I guess this is wrong. The problem with >> what I say here is that longjmp() and setjmp() are incompatible with >> the stack unwinding used by C++ destructors in general (exceptions are >

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 13:40:06 -0700, Peter Geoghegan wrote: > On Tue, Aug 16, 2016 at 1:29 PM, Peter Geoghegan wrote: > > IMV, it would be useful to use C++ classes (and even template classes) > > for a small number of data structures, while still largely adhering to > > earlier practices (this is what G

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 3:29 PM, Andres Freund wrote: Well, having typed pg_list.h style lists, ilist.h linked lists, hash-tables, and proper typechecks for pg_nodes.h instead of the NodeTag stuff, would surely make life easier. I certainly wish parts of the system brought code and "data" together in a bet

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:29 PM, Peter Geoghegan wrote: > IMV, it would be useful to use C++ classes (and even template classes) > for a small number of data structures, while still largely adhering to > earlier practices (this is what GCC did). Specifically, a few modules > such as StringInfo, co

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 12:59:24 -0400, Tom Lane wrote: > 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

Re: [HACKERS] [GENERAL] C++ port of Postgres

I'm sure this wasn't your intent, but the tone of your response is part of why people don't get involved with Postgres development... On 8/16/16 10:39 AM, Aleksander Alekseev wrote: Well, well, well. Another C vs C++ holly war, really? Please note that you're the only person in the entire thr

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 9:59 AM, Tom Lane wrote: > 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++. Alm

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 18:52:39 +0300, Heikki Linnakangas wrote: > On 08/16/2016 05:47 PM, Jim Nasby wrote: > > I realize there's little technical reason why we *need* C++ support. The > > level if discipline applied to our codebase negates some of the benefits > > of C++. But maintaining the discipline tak

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 12:53 PM, Joy Arulraj wrote: > The whole thing would make a lot more sense given a credible design > for error handling that keeps both languages happy. Well, getting so that we can at least compile in both systems would certainly increase the chances of somebody being

Re: [HACKERS] [GENERAL] C++ port of Postgres

2016-08-16 18:52 GMT+03:00 Heikki Linnakangas : > On 08/16/2016 05:47 PM, Jim Nasby wrote: >> >> I realize there's little technical reason why we *need* C++ support. The >> level if discipline applied to our codebase negates some of the benefits >> of C++. But maintaining the discipline takes a lot

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 1:13 PM, Robert Haas wrote: > On Tue, Aug 16, 2016 at 12:59 PM, Tom Lane wrote: > > 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 o

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 12:59 PM, Tom Lane wrote: > 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

Re: [HACKERS] [GENERAL] C++ port of Postgres

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++ cod

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 08/16/2016 09:33 AM, Robert Haas wrote: On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby wrote: On 8/16/16 2:52 AM, Gavin Flower wrote: I agree with your statement that one of our biggest problems is getting more developers interested in working on PostgreSQL. Even if there's only a 10% chanc

Re: [HACKERS] [GENERAL] C++ port of Postgres

On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby wrote: > On 8/16/16 2:52 AM, Gavin Flower wrote: >> In both cases, part of the motivation to change from C was to appeal to >> new developers - from what I remember of the discussions. > > Moving this to -hackers. Original thread at [1]. > > tl;dr: A C++

Re: [HACKERS] [GENERAL] C++ port of Postgres

Aleksander Alekseev wrote: You are right, there is none. First: trees in parser, planer and etc. Second: normal exception. Two big projects lately move to C++ from C: GCC, Mesa You can read their reasons. Only C++ we can use without full rewrite currently. (or ObjectC maybe) If we wish fix C

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 08/16/2016 05:47 PM, Jim Nasby wrote: I realize there's little technical reason why we *need* C++ support. The level if discipline applied to our codebase negates some of the benefits of C++. But maintaining the discipline takes a lot of time and effort, and makes it more difficult to attract

Re: [HACKERS] [GENERAL] C++ port of Postgres

Well, well, well. Another C vs C++ holly war, really? > > In both cases, part of the motivation to change from C was to > > appeal to new developers - from what I remember of the > > discussions. > > Moving this to -hackers. Original thread at [1]. > > tl;dr: A C++ port of Postgres has been cr

Re: [HACKERS] [GENERAL] C++ port of Postgres

Jim Nasby wrote: My hope is that existing hackers can agree on a reasonable way forward and guide/assist new folks that are interested in walking that path. I tried this path. https://github.com/stalkerg/postgres_cpp And I fully support this desire. But I'm in the minority. I also like the

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 8/16/16 2:52 AM, Gavin Flower wrote: In both cases, part of the motivation to change from C was to appeal to new developers - from what I remember of the discussions. Moving this to -hackers. Original thread at [1]. tl;dr: A C++ port of Postgres has been created, and several folks on gener