C++ port of Postgres

On 8/14/2016 2:05 PM, Joy Arulraj wrote:

We have ported Postgres over to the C++ language (C++11 standard).

https://github.com/jarulraj/postgresql-cpp

Our goal is to use certain features of the C++ language and its
standard library to simplify coding, improve code reuse, and avoid
bugs. Peter's article titled `Moving to C++
<https://petereisentraut.blogspot.com/2013/05/moving-to-c.html&gt;` was a
source of inspiration for us.

does this compile with the non-GCC compilers that postgres gets built
with, for instance, IBM XLC++ on AIX, Oracle Studio C++ on Solaris,
Microsoft Visual C++ on MS Windows, CLang on BSD ? what about popular
platforms like RHEL 6, where gcc is 4.4.7 ?

--
john r pierce, recycling bits in santa cruz

Hi Joy,

2016-08-15 0:05 GMT+03:00 Joy Arulraj <jarulraj@cs.cmu.edu>:

Hi folks --

We have ported Postgres over to the C++ language (C++11 standard).

https://github.com/jarulraj/postgresql-cpp

Our goal is to use certain features of the C++ language and its standard
library to simplify coding, improve code reuse, and avoid bugs. Peter's
article titled `Moving to C++` was a source of inspiration for us.

What about the exceptions? Are you using them?

--
// Dmitry.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Hi Dmitry -- We currently don't use exceptions, but we can certainly use
them in the port. We can also use STL and smart pointers to simplify
development and minimize memory bugs.

On Aug 14, 2016 5:41 PM, "Dmitry Igrishin" <dmitigr@gmail.com> wrote:

I agree with this project, I dont like any setjmp/longjmp and the
like. It just fighting against the nature of c++ language. Building
either from scratch gcc48 or clang381 were easy nowdays on either old
linux debian squeeze or centos 5. PS: I had this requirement
circumtances.

On 8/15/16, Joy Arulraj <jarulraj@cs.cmu.edu> wrote:

Hi Dmitry -- We currently don't use exceptions, but we can certainly use
them in the port. We can also use STL and smart pointers to simplify
development and minimize memory bugs.

On Aug 14, 2016 5:41 PM, "Dmitry Igrishin" <dmitigr@gmail.com> wrote:

Hi Joy,

2016-08-15 0:05 GMT+03:00 Joy Arulraj <jarulraj@cs.cmu.edu>:

Hi folks --

We have ported Postgres over to the C++ language (C++11 standard).

https://github.com/jarulraj/postgresql-cpp

Our goal is to use certain features of the C++ language and its
standard
library to simplify coding, improve code reuse, and avoid bugs. Peter's
article titled `Moving to C++` was a source of inspiration for us.

What about the exceptions? Are you using them?

--
// Dmitry.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Kang -- Yes, this is one of the reasons why we chose to do this.

John -- We have not compiled it with non-GCC compilers. But, I presume that
the changes required to support compilation with other compilers should be
minimal as we don't rely on any compiler-specific features.

On Sun, Aug 14, 2016 at 6:30 PM, kang joni <kangjoni76@gmail.com> wrote:

Just wondering what the end goal is for this project... Is it to just
maintain an up to date Postgres fork that will compile with a C++ compiler?
Is it to get a conversation going for a direction for Postgres itself to
move? The former I don't see gaining much traction or doing all that much
for the state of the project. The latter possibly could if the community
gets on board.

Thanks,
-Adam

Just wondering what the end goal is for this project... Is it to just maintain an up to date Postgres fork that will compile with a C++ compiler? Is it to get a conversation going for a direction for Postgres itself to move? The former I don't see gaining much traction or doing all that much for the state of the project. The latter possibly could if the community gets on board.

I would certainly hope the latter. Having done some work on extension functions and an extension language for Postgres, the current situation can be quite limiting.

* Parts of my code could only be written in C++, so I finished up with a mixed build, which is not ideal.

* My other issue was dealing with the Datum macros. Type-safe inline C++ functions would help reduce dumb errors.

Not compelling reasons perhaps, but just a vote for a move in that direction, some time.

Regards

David M Bennett FACS

_____

Andl - A New Database Language - andl.org

On 16/08/16 18:24, dandl wrote:

Just wondering what the end goal is for this project... Is it to just
maintain an up to date Postgres fork that will compile with a C++
compiler? Is it to get a conversation going for a direction for
Postgres itself to move? The former I don't see gaining much traction
or doing all that much for the state of the project. The latter
possibly could if the community gets on board.

I would certainly hope the latter. Having done some work on extension
functions and an extension language for Postgres, the current
situation can be quite limiting.

·Parts of my code could only be written in C++, so I finished up with
a mixed build, which is not ideal.

·My other issue was dealing with the Datum macros. Type-safe inline
C++ functions would help reduce dumb errors.

Not compelling reasons perhaps, but just a vote for a move in that
direction, some time.

Regards

David M Bennett FACS

/
------------------------------------------------------------------------
/

/Andl - A New Database Language - andl.org/

I note that gcc itself is now written in C++, and so is squid (web
proxy)...

In both cases, part of the motivation to change from C was to appeal to
new developers - from what I remember of the discussions.

Cheers,
Gavin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Well done. This is a much needed conversion. As Peter’s article says, it does open up more opportunities.

From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Joy Arulraj
Sent: 14 August 2016 22:06
To: pgsql-general@postgresql.org
Subject: [GENERAL] C++ port of Postgres

Hi folks --

We have ported Postgres over to the C++ language (C++11 standard).

https://github.com/jarulraj/postgresql-cpp

Our goal is to use certain features of the C++ language and its standard library to simplify coding, improve code reuse, and avoid bugs. Peter's article titled `Moving to C++ <https://petereisentraut.blogspot.com/2013/05/moving-to-c.html&gt; ` was a source of inspiration for us.

Regards.

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
general have commented that this makes it easier to work with the
Postgres codebase. This potentially attracts more developers to the
project. I hope we can find a way to pull these folks into the fold.

People in core have complained that we don't have enough hackers coming
in (which I agree with). Part of that is lack of familiarity with C.

I think we can all agree that a C++ fork of Postgres would be a huge
waste of time, so the question becomes should core postgres start
supporting C++.

Peter wrote a blog about this in 2013 that makes some good arguments
[2]: ; in particular "easing into" this by first officially supporting C++ compilation. I also like the idea of investigating Rust.
compilation. I also like the idea of investigating Rust.

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 new contributors. 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.

1:
/messages/by-id/CABgyVxDBd3EvRdo-Rd6eo8QPEqV8=ShaU2SJfo16wfE0R-hXTA@mail.gmail.com
2: https://petereisentraut.blogspot.com/2013/05/moving-to-c.html
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 idea of investigating Rust.

I am working on it last few weeks. But it's like seek blocks for new DB. I
don't know how we can insert Rust code into Postgres spaghetti.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 created, and several folks on
general have commented that this makes it easier to work with the
Postgres codebase. This potentially attracts more developers to the
project. I hope we can find a way to pull these folks into the fold.

Who are these "folks"? How many more developers it would attract
_exactly_, not potentially?

People in core have complained that we don't have enough hackers
coming in (which I agree with). Part of that is lack of familiarity
with C.

One again, which "people"? I've seen people complained that there is
not enough code reviewers and testers. I doubt very much its something
C++ will help with.

I think we can all agree that a C++ fork of Postgres would be a huge
waste of time, so the question becomes should core postgres start
supporting C++.

Peter wrote a blog about this in 2013 that makes some good arguments
[2]; in particular "easing into" this by first officially supporting
C++ compilation. I also like the idea of investigating Rust.

And I wrote a blog post (in Russian) [1]http://eax.me/c-vs-cpp/ in 2016 why nobody should (if
they can) write a new code in C++. In my opinion Rust looks way more
promising. However I personally prefer to wait like 5 years before
using a new and shiny technology. This is also something I blogged
about (in Russian [2]http://eax.me/cpp-will-never-die/, translation [3]http://www.viva64.com/en/b/0324/).

I realize there's little technical reason why we *need* C++ support.

You are right, there is none.

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 new contributors.

There are companies. They hire developers who write code. Doesn't
really matters in which language.

Long story short - I strongly believe you are trying to solve a problem
that doesn't exist. And probably create a few new ones.

[1]: http://eax.me/c-vs-cpp/
[2]: http://eax.me/cpp-will-never-die/
[3]: http://www.viva64.com/en/b/0324/

--
Best regards,
Aleksander Alekseev

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 16, 2016 at 3:52 AM, Gavin Flower <GavinFlower@archidevsys.co.nz

wrote:

On 16/08/16 18:24, dandl wrote:

Just wondering what the end goal is for this project... Is it to just
maintain an up to date Postgres fork that will compile with a C++ compiler?
Is it to get a conversation going for a direction for Postgres itself to
move? The former I don't see gaining much traction or doing all that much
for the state of the project. The latter possibly could if the community
gets on board.

I was kind of hoping that this might start off a coversation on getting
postgres to support C++.

I would certainly hope the latter. Having done some work on extension

functions and an extension language for Postgres, the current situation can
be quite limiting.

·Parts of my code could only be written in C++, so I finished up with a
mixed build, which is not ideal.

·My other issue was dealing with the Datum macros. Type-safe inline C++
functions would help reduce dumb errors.

Not compelling reasons perhaps, but just a vote for a move in that
direction, some time.

I concur.

Thanks, I do hope so.

On Tue, Aug 16, 2016 at 7:00 AM, FarjadFarid(ChkNet) <
farjad.farid@checknetworks.com> 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 takes a lot of time and effort,
and makes it more difficult to attract new contributors.

I suspect that it would take as much discipline to keep a C++ codebase
readable, as the current C codebase. If not more.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 limitations.

--
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby <Jim.Nasby@bluetreble.com> 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++ port of Postgres has been created, and several folks on general
have commented that this makes it easier to work with the Postgres codebase.
This potentially attracts more developers to the project. I hope we can find
a way to pull these folks into the fold.

People in core have complained that we don't have enough hackers coming in
(which I agree with). Part of that is lack of familiarity with C.

I think we can all agree that a C++ fork of Postgres would be a huge waste
of time, so the question becomes should core postgres start supporting C++.

Peter wrote a blog about this in 2013 that makes some good arguments [2]; in
particular "easing into" this by first officially supporting C++
compilation. I also like the idea of investigating Rust.

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 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% chance that something like this will help, why not?
We're not talking about moving the earth.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 08/16/2016 09:33 AM, Robert Haas wrote:

On Tue, Aug 16, 2016 at 10:47 AM, Jim Nasby <Jim.Nasby@bluetreble.com> 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% chance that something like this will help, why not?
We're not talking about moving the earth.

Right. It is just reality that less people are learning C which means
less people will be interested in joining a project that is focused or
(required) to be C.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> 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