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

2016-08-16 Thread Joy Arulraj
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 systems would
>> certainly increase the chances of somebody being willing to work on
>> such a design.  And if nobody ever does, then at least people who want
>> to fork and do research projects based on PostgreSQL will have
>> slightly less work to do when they want to hack it up.  PostgreSQL
>> seems to be a very popular starting point for research work, but a
>> paper I read recently complained about the antiquity of our code base.
>> I prefer to call that backward-compatibility, but at some point people
>> stop thinking of you as backward-compatible and instead think of you
>> as simply backward.
>>
>> I agree, this was the main reason why we wanted to add support for C++.
>>
>
> Joy, do you have an idea what a *minimally invasive* patch for C++ support
> would look like? That's certainly the first step here.
>
>
Jim -- I believe that the patch will be roughly 6K lines long. The majority
of the changes correspond to handling language keyword conflicts.

https://github.com/jarulraj/postgresql-cpp/compare/182656bf32b99c96e5cd9dc59ece4c20149787fb...7ef6f472b53a83a4cedd0222b41345c0f74fae1e

I must mention that some of the changes I have made preclude the
possibility of supporting compilation with both C and C++ compilers.
However, I am certain that this limitation can be circumvented with some
clever hacking.


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


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

2016-08-16 Thread Joy Arulraj
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 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.
>
> Yeah, that could be nice.
>
> > 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.
>
> I agree, but we don't have to agree to change everything before we
> agree to change anything.  If we got an agreement to try to make
> everything compile in both languages, that'd be more agreement than
> we've ever had before, and I'd rather take that agreement and run than
> look a gift horse in the mouth.
>
> > 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 willing to work on
> such a design.  And if nobody ever does, then at least people who want
> to fork and do research projects based on PostgreSQL will have
> slightly less work to do when they want to hack it up.  PostgreSQL
> seems to be a very popular starting point for research work, but a
> paper I read recently complained about the antiquity of our code base.
> I prefer to call that backward-compatibility, but at some point people
> stop thinking of you as backward-compatible and instead think of you
> as simply backward.
>
>
I agree, this was the main reason why we wanted to add support for C++.


> > 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.
>
> True.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>