Re: PostgreSQL future ideas

Dear PG hackers,

Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear your opinion.

(You can take your M16 and start shooting now)

Regards,
Gevik

On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl> wrote:
>
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming language
> like C++? Of course there are some minor obstacles like a new OO design,
> this being a gigantic task to perform and rewriting almost everything etc...
> I am very interested to hear your opinion.

The plan is to start porting it to Java after the next release -
probably at the beginning of April.

:-p

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Gevik Babakhani wrote:
> Has there been any idea to port PG to a more modern programming language
> like C++?

No.

> (You can take your M16 and start shooting now)

My pleasure ;-).

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Fri, 19 Sep 2008 21:54:53 +0200
"Gevik Babakhani" <pgdev(at)xs4all(dot)nl> wrote:

>
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming
> language like C++? Of course there are some minor obstacles like a
> new OO design, this being a gigantic task to perform and rewriting
> almost everything etc... I am very interested to hear your opinion.
>
> (You can take your M16 and start shooting now)

No shooting required, your email client reached out and killed you when
you hit send.

Joshua D. Drake

>
> Regards,
> Gevik
>
>

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

It might look like an impossible goal to achieve.. But if there is any
serious plan/idea/ammo for this, I believe it would be very beneficial to
the
continuity of PG.

Regards,
Gevik.

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Dave Page
> Sent: Friday, September 19, 2008 9:58 PM
> To: Gevik Babakhani
> Cc: PGSQL Hackers
> Subject: Re: [HACKERS] PostgreSQL future ideas
>
> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani
> <pgdev(at)xs4all(dot)nl> wrote:
> >
> > Dear PG hackers,
> >
> > Has there been any idea to port PG to a more modern programming
> > language like C++? Of course there are some minor obstacles
> like a new
> > OO design, this being a gigantic task to perform and
> rewriting almost everything etc...
> > I am very interested to hear your opinion.
>
> The plan is to start porting it to Java after the next
> release - probably at the beginning of April.
>
> :-p
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
>
> --
> 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
>

On Fri, 19 Sep 2008 20:57:36 +0100
"Dave Page" <dpage(at)pgadmin(dot)org> wrote:
> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl> wrote:
> > Has there been any idea to port PG to a more modern programming language
> > like C++? Of course there are some minor obstacles like a new OO design,
>
> The plan is to start porting it to Java after the next release -
> probably at the beginning of April.

I don't think that we should rush into any one language without
checking the alternatives. Personally I think we should port everything
to Intercal.

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

On Fri, Sep 19, 2008 at 4:32 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl> wrote:
> It might look like an impossible goal to achieve.. But if there is any
> serious plan/idea/ammo for this, I believe it would be very beneficial to
> the continuity of PG.

I don't think so. Firebird rewrote their entire kernel to be C++ and
in doing so, lost a lot of maturity along-the-way IMHO. Similarly
switching to another language would require a large number of people
not only familiar with Postgres internals, but also in the new
programming language; it wouldn't make sense to switch to something
like C++ and not make full use of the language.

I don't see how you think it will help. Most universities (here in
the US at least), are shying away from teaching C/C++. So, in the
long run, I don't see how that would really help us get more developer
involvement.

--
Jonah H. Harris, Senior DBA
myYearbook.com

On Fri, Sep 19, 2008 at 08:57:36PM +0100, Dave Page wrote:
> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl> wrote:
> >
> > Dear PG hackers,
> >
> > Has there been any idea to port PG to a more modern programming language
> > like C++? Of course there are some minor obstacles like a new OO design,
> > this being a gigantic task to perform and rewriting almost everything etc...
> > I am very interested to hear your opinion.
>
> The plan is to start porting it to Java after the next release -
> probably at the beginning of April.

Already done!

http://www.postgresql.org/community/weeklynews/pwn20050401

Cheers,
David
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

> I don't think so. Firebird rewrote their entire kernel to be
> C++ and in doing so, lost a lot of maturity along-the-way

I would not make any sense to put/group functions in one or more classes
without using the OO patterns. I guess this is what Firebird has done.

> Similarly switching to another language would require
> a large number of people not only familiar with Postgres
> internals, but also in the new programming language; it
> wouldn't make sense to switch to something like C++ and not
> make full use of the language.

True. It would be an enormous task...

> I don't see how you think it will help. Most universities
> (here in the US at least), are shying away from teaching
> C/C++. So, in the long run, I don't see how that would
> really help us get more developer involvement.

Unless I am very off. C++ is a natural choice when porting (upgrading) ANSI
C application.
As far as I know, most universities teach some sort of OO programming
language like JAVA or C# to help students understand OO programming.
I understand that C++ is less popular but JAVA/C# would be the wrong choice
for this.

Regards,
Gevik.

>
> --
> Jonah H. Harris, Senior DBA
> myYearbook.com
>
> --
> 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
>

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Jonah H. Harris
> Sent: Friday, September 19, 2008 10:39 PM
> To: Gevik Babakhani
> Cc: Dave Page; PGSQL Hackers;
> heikki(dot)linnakangas(at)enterprisedb(dot)com; jd(at)commandprompt(dot)com
> Subject: Re: [HACKERS] PostgreSQL future ideas
>
> On Fri, Sep 19, 2008 at 4:32 PM, Gevik Babakhani
> <pgdev(at)xs4all(dot)nl> wrote:
> > It might look like an impossible goal to achieve.. But if
> there is any
> > serious plan/idea/ammo for this, I believe it would be very
> beneficial
> > to the continuity of PG.
>
> I don't think so. Firebird rewrote their entire kernel to be
> C++ and in doing so, lost a lot of maturity along-the-way
> IMHO. Similarly switching to another language would require
> a large number of people not only familiar with Postgres
> internals, but also in the new programming language; it
> wouldn't make sense to switch to something like C++ and not
> make full use of the language.
>
> I don't see how you think it will help. Most universities
> (here in the US at least), are shying away from teaching
> C/C++. So, in the long run, I don't see how that would
> really help us get more developer involvement.
>
> --
> Jonah H. Harris, Senior DBA
> myYearbook.com
>
> --
> 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
>

> Already done!
>
> http://www.postgresql.org/community/weeklynews/pwn20050401
>

Yes, yes COBOL :) PostCobolSQL

On Fri, Sep 19, 2008 at 09:54:53PM +0200, Gevik Babakhani wrote:
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming
> language like C++? Of course there are some minor obstacles like a
> new OO design, this being a gigantic task to perform and rewriting
> almost everything etc... I am very interested to hear your opinion.
>
> (You can take your M16 and start shooting now)

I won't get out the '16, but I *will* ask for some evidence in the
form of other projects of at least comparable size that have switched
languages successfully.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, 19 Sep 2008 23:01:15 +0200
"Gevik Babakhani" <pgdev(at)xs4all(dot)nl> wrote:

> Unless I am very off. C++ is a natural choice when porting
> (upgrading) ANSI C application.
> As far as I know, most universities teach some sort of OO programming
> language like JAVA or C# to help students understand OO programming.
> I understand that C++ is less popular but JAVA/C# would be the wrong
> choice for this.

I think the better question about all of this is:

What is the problem we are trying to solve?

Providing solutions that are looking for problems doesn't help us.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

> I think the better question about all of this is:
> What is the problem we are trying to solve?
> Providing solutions that are looking for problems doesn't help us.
> Sincerely,

Perhaps the current codebase and design in C will serve us for years and
years to come. In fact there is no doubt about that and switching to an OO
design is no easy task. But times change and technologies evolve. So should
any software solution that is hoping to continue and compete with other
competitors of the same kind.

Procedural programming languages like C may have been languages of choice
for many years but they gradually loose developer audience just because of
the reason above. I am afraid PG is no exception here.

>
> Joshua D. Drake
>
>
> --
> The PostgreSQL Company since 1997:
> http://www.commandprompt.com/ PostgreSQL Community
> Conference: http://www.postgresqlconference.org/
> United States PostgreSQL Association:
> http://www.postgresql.us/ Donate to the PostgreSQL Project:
> http://www.postgresql.org/about/donate
>
>
>
> --
> 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
>

All,

> I don't see how you think it will help. Most universities (here in
> the US at least), are shying away from teaching C/C++. So, in the
> long run, I don't see how that would really help us get more developer
> involvement.

Last I checked, we *weren't* having any problem recruiting developers. If
the project has a problem right now, it's dealing with the tremendous
output of the developers we do have. And infrastructure.

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

Gevik Babakhani wrote:
>> I think the better question about all of this is:
>> What is the problem we are trying to solve?
>> Providing solutions that are looking for problems doesn't help us.
>> Sincerely,
>>
>
> Perhaps the current codebase and design in C will serve us for years and
> years to come. In fact there is no doubt about that and switching to an OO
> design is no easy task. But times change and technologies evolve. So should
> any software solution that is hoping to continue and compete with other
> competitors of the same kind.
>
> Procedural programming languages like C may have been languages of choice
> for many years but they gradually loose developer audience just because of
> the reason above. I am afraid PG is no exception here.
>

A major problem I have with this suggestion is that PostgreSQL would
indeed be equivalent or better re-written in another language. All
PostgreSQL benchmarking and design decisions have been based upon
measuring the performance of PostgreSQL written in C for common
platforms. At it's most basic, if you were to do a strict 1:1
translation of PostgreSQL from C to Java, I feel confident in
guaranteeing that you will see a 10 times or more drop in performance.
Why? Because what is fast in Java is not the same as what is fast in C.
The design decisions would all need to be revisited, and the effect
would be exactly as already suggested - an immature design, competing
against other mature designs.

From C to C++ is only a smaller leap in the sense that pieces of
PostgreSQL could be migrated at a time. The result is still that an
OO-modelled PostgreSQL would be significantly different from a
procedure-modelled PostgreSQL, and you would always be facing the
compromise of: 1) Should re-write this part to be OO? or 2) Should we
leave it alone for now (and then, why bother using C++?).

Somebody working on a thesis or with thousands of hours of spare time
and no inclination to work on any other part, might prove that many of
the PostgreSQL technologies port well to another language - but it is
far more likely that the result will be a bust.

I'd rather core developer effort was spent doing what they are doing today.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>

Joshua Drake wrote:
> On Fri, 19 Sep 2008 23:01:15 +0200
> "Gevik Babakhani" <pgdev(at)xs4all(dot)nl> wrote:
>
>> Unless I am very off. C++ is a natural choice when porting
>> (upgrading) ANSI C application.
>> As far as I know, most universities teach some sort of OO programming
>> language like JAVA or C# to help students understand OO programming.
>> I understand that C++ is less popular but JAVA/C# would be the wrong
>> choice for this.
>
> I think the better question about all of this is:
>
> What is the problem we are trying to solve?
>
> Providing solutions that are looking for problems doesn't help us.
>
> Sincerely,
>
> Joshua D. Drake
>
>

fixing something that isn't broken is never a good idea. I see no
advantage switching to c++. Joshua is correct, what are you trying to
do that would require c++? If its OO design, well you don't need an OO
language for that.

C isn't going anywhere anytime soon. Look at its history, it has
survived its 'replacements' over and over again. The most popular
kernels, shells and applications are all still written in C (new and
old). Where are the warning signs that it is dwindling?

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Gevik Babakhani wrote:
>> I think the better question about all of this is:
>> What is the problem we are trying to solve?
>> Providing solutions that are looking for problems doesn't help us.
>> Sincerely,
>>
>
> Perhaps the current codebase and design in C will serve us for years and
> years to come. In fact there is no doubt about that and switching to an OO
> design is no easy task. But times change and technologies evolve. So should
> any software solution that is hoping to continue and compete with other
> competitors of the same kind.
>
> Procedural programming languages like C may have been languages of choice
> for many years but they gradually loose developer audience just because of
> the reason above. I am afraid PG is no exception here.
>
>

That's a two way street. I have far more experience in writing C than
C++. No doubt I could adapt, but it would certainly slow me down for a
while at least.

Frankly, this looks like a solution in search of a problem. When OS
kernels are all written in C++ I might accept that there is a good case,
but I see no sign of anything like that happening.

cheers

andrew

Thank you all for your opinion.

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Andrew Dunstan
> Sent: Saturday, September 20, 2008 12:53 AM
> To: Gevik Babakhani
> Cc: 'Joshua Drake'; 'Jonah H. Harris'; 'Dave Page'; 'PGSQL
> Hackers'; heikki(dot)linnakangas(at)enterprisedb(dot)com;
> david(at)fetter(dot)org; josh(at)agliodbs(dot)com
> Subject: Re: [HACKERS] PostgreSQL future ideas
>
>
>
> Gevik Babakhani wrote:
> >> I think the better question about all of this is:
> >> What is the problem we are trying to solve?
> >> Providing solutions that are looking for problems doesn't help us.
> >> Sincerely,
> >>
> >
> > Perhaps the current codebase and design in C will serve us
> for years
> > and years to come. In fact there is no doubt about that and
> switching
> > to an OO design is no easy task. But times change and technologies
> > evolve. So should any software solution that is hoping to
> continue and
> > compete with other competitors of the same kind.
> >
> > Procedural programming languages like C may have been languages of
> > choice for many years but they gradually loose developer
> audience just
> > because of the reason above. I am afraid PG is no exception here.
> >
> >
>
> That's a two way street. I have far more experience in writing C than
> C++. No doubt I could adapt, but it would certainly slow me down for a
> while at least.
>
> Frankly, this looks like a solution in search of a problem. When OS
> kernels are all written in C++ I might accept that there is a
> good case,
> but I see no sign of anything like that happening.
>
> cheers
>
> andrew
>
> --
> 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
>

I'm surprised no one pointed out that Postgres has *already* been ported
to a new language once. It was originally written in Lisp, and was
rewritten in C sometime in the Berkeley years. (Anyone know exactly
when or by whom? I don't.) You can still see the effects of that
origin in the system's liking for list-based data structures.

But the code base was an order of magnitude smaller and simpler back
then, meaning that a fresh port would be at least an order of magnitude
harder. Like other respondents, I'm not seeing where we'd get benefits
commensurate with the cost.

regards, tom lane

> C isn't going anywhere anytime soon. Look at its history, it has survived
> its 'replacements' over and over again. The most popular kernels, shells
> and applications are all still written in C (new and old). Where are the
> warning signs that it is dwindling?

To add to this:

It's easy to underestimate the effect that writing in almost anything
else has on performance. I once had a job working on a research
operating system written in C++. It was about 10x slower than
whichever flavor of BSD we were using at the time. There were a lot
of reasons for this, but I remember that overuse of heavy-weight
template classes was definitely one of them (not to mention a huge
source of code bloat). Ripping that logic out and replacing it with
something more, erm, C-like paid huge dividends.

There's no problem with using a higher-level language for your
application programming - I do almost all of my coding these days in
Perl or, as it happens, PL/pgsql. But you really don't want that
programming language to itself be written in another high-level
language. Core system components like your kernel and database and
compiler need to be fast, and it's pretty hard to get that in anything
other than C. You could probably make C++ do the job passably well,
but only if you avoid using some of the more inefficient language
features... in other words, only if you make it look as much like C as
possible.

...Robert

On Fri, 19 Sep 2008, "Gevik Babakhani" <pgdev(at)xs4all(dot)nl> writes:
> Has there been any idea to port PG to a more modern programming language
> like C++? Of course there are some minor obstacles like a new OO design,
> this being a gigantic task to perform and rewriting almost everything etc...
> I am very interested to hear your opinion.

This topic was discussed many times before in the past. See mailing list
archives. If you have any _alternative_ ideas to say to previous
discussions, I think developers will be appreciated to hear it.

Regards.

On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
> On Fri, 19 Sep 2008 20:57:36 +0100
> "Dave Page" <dpage(at)pgadmin(dot)org> wrote:
> > On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl> wrote:
> > > Has there been any idea to port PG to a more modern programming language
> > > like C++? Of course there are some minor obstacles like a new OO design,
> >
> > The plan is to start porting it to Java after the next release -
> > probably at the beginning of April.
>
> I don't think that we should rush into any one language without
> checking the alternatives. Personally I think we should port everything
> to Intercal.

We should rewrite it to something that has no visual noise, so
attracting new developers would be easier.

My choice would be whitespace , see
http://en.wikipedia.org/wiki/Whitespace_(programming_language)

-----------------
Hannu Krosing

On Sat, 20 Sep 2008 13:47:10 +0300
Hannu Krosing <hannu(at)2ndQuadrant(dot)com> wrote:
> On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
> > I don't think that we should rush into any one language without
> > checking the alternatives. Personally I think we should port everything
> > to Intercal.
>
> My choice would be whitespace , see
> http://en.wikipedia.org/wiki/Whitespace_(programming_language)

Hey, we could write two modules into each file, one in Intercal and
another in Whitespace. :-)

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Who can resist the programming language game?

Le 19 sept. 08 à 22:37, D'Arcy J.M. Cain a écrit :
> On Fri, 19 Sep 2008 20:57:36 +0100
> "Dave Page" <dpage(at)pgadmin(dot)org> wrote:
>> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev(at)xs4all(dot)nl>
>> wrote:
>>> Has there been any idea to port PG to a more modern programming
>>> language
>>> like C++? Of course there are some minor obstacles like a new OO
>>> design,
>>
>> The plan is to start porting it to Java after the next release -
>> probably at the beginning of April.
>
> I don't think that we should rush into any one language without
> checking the alternatives. Personally I think we should port
> everything
> to Intercal.

May I recall Greenspun's Tenth Rule of Programming: "any sufficiently
complicated C or Fortran program contains an ad hoc informally-
specified bug-ridden slow implementation of half of Common Lisp".

Regards,
- --
dim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkjVVZUACgkQlBXRlnbh1bl/6gCcDhLEAdy+pZnjGnKSly3jmZqC
5pYAoMbseRc3Di49dRnr4XLDIGJOApFz
=Qj2e
-----END PGP SIGNATURE-----

On Sat, 2008-09-20 at 09:06 -0400, D'Arcy J.M. Cain wrote:
> On Sat, 20 Sep 2008 13:47:10 +0300
> Hannu Krosing <hannu(at)2ndQuadrant(dot)com> wrote:
> > On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote:
> > > I don't think that we should rush into any one language without
> > > checking the alternatives. Personally I think we should port everything
> > > to Intercal.
> >
> > My choice would be whitespace , see
> > http://en.wikipedia.org/wiki/Whitespace_(programming_language)
>
> Hey, we could write two modules into each file, one in Intercal and
> another in Whitespace. :-)

Good idea! if we are smart, we can interweave them so that the
whitespace inside intercal forms the source code of the Whitespace
program.

That would almost be Literate Programming - if you are not sure, what
some part of the program does, you can immediately look at the other
implementation.

---------------
Hannu

pgdev(at)xs4all(dot)nl ("Gevik Babakhani") writes:
> It might look like an impossible goal to achieve.. But if there is
> any serious plan/idea/ammo for this, I believe it would be very
> beneficial to the continuity of PG.

Actually, I imagine that such a rewrite would run a very considerable
risk of injuring the continuity of PostgreSQL VERY BADLY, to the point
of causing community fractures and forks of the codebase.

When you write something in C++, you have to pick a subset of the
language that is supported fairly identically (in semantics) by all of
the compilers that you wish to support.

Seeing as how PostgreSQL is already a mature system written in C, a
rewrite into C++, *which is a different language* that is NOT simply a
superset of C functionality, would require substantial effort, lead to
fractious disagreements, and would, without ANY doubt, fracture the
code base into *AT LEAST* two versions, namely:

a) The existing C code base, and
b) One (possibly more) C++ rewrites

This does not strike me as a particularly useful exercise. If I
intended such a rewrite, I'd much rather consider using something
*interestingly* different from C, like Erlang or Eiffel or Haskell.
--
"cbbrowne","@","linuxdatabases.info"
http://linuxfinances.info/info/sgml.html
For a good prime call:
391581 * 2^216193 - 1
-- smr2(at)cornell(dot)edu (Szymon Rusinkiewicz)

Gevik Babakhani wrote:
> Has there been any idea to port PG to a more modern programming language
> like C++? Of course there are some minor obstacles like a new OO design,
> this being a gigantic task to perform and rewriting almost everything etc...
> I am very interested to hear your opinion.

Gevik, of course you're free to fork the project and try this yourself.

I'd caution you that neither OO nor C++ are particularly "modern"
(Stroustrup's objects-on-C work dates back to the 1970's). And that
of the OO languages, C++ is one of the worst in terms of OO capabilities.

If your theory favoring a "modern" language is thinking that this'll
give you efficiencies (either in development time or runtime), you
might consider Erlang instead. It's Functional and Concurrency and
Fault Tolerance oriented features would IMHO be more useful for large
reliable servers than anything C++ has to offer.

Chris,

> This does not strike me as a particularly useful exercise. If I
> intended such a rewrite, I'd much rather consider using something
> *interestingly* different from C, like Erlang or Eiffel or Haskell.

And if you were going to do *that*, you'd also rewrite the database to
operate entirely in-memory over a cluster of anonymous servers.

At which point the only thing left of PostgreSQL would be the parser.
Hmmm, this is sounding familiar somehow ...

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

Robert Haas wrote:
> > C isn't going anywhere anytime soon. Look at its history, it has survived
> > its 'replacements' over and over again. The most popular kernels, shells
> > and applications are all still written in C (new and old). Where are the
> > warning signs that it is dwindling?
>
> To add to this:
>
> It's easy to underestimate the effect that writing in almost anything
> else has on performance. I once had a job working on a research
> operating system written in C++. It was about 10x slower than
> whichever flavor of BSD we were using at the time. There were a lot
> of reasons for this, but I remember that overuse of heavy-weight
> template classes was definitely one of them (not to mention a huge
> source of code bloat). Ripping that logic out and replacing it with
> something more, erm, C-like paid huge dividends.
>
> There's no problem with using a higher-level language for your
> application programming - I do almost all of my coding these days in
> Perl or, as it happens, PL/pgsql. But you really don't want that
> programming language to itself be written in another high-level
> language. Core system components like your kernel and database and
> compiler need to be fast, and it's pretty hard to get that in anything
> other than C. You could probably make C++ do the job passably well,
> but only if you avoid using some of the more inefficient language
> features... in other words, only if you make it look as much like C as
> possible.

Agreed. If we went with C++ we would need to be able to turn _off_ some
C++ features to keep performance reasonable. I can see trying to use a
_few_ C++ features, but in general it isn't worth the effort.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Gevik Babakhani napsal(a):
> Dear PG hackers,
>
> Has there been any idea to port PG to a more modern programming language
> like C++? Of course there are some minor obstacles like a new OO design,
> this being a gigantic task to perform and rewriting almost everything etc...
> I am very interested to hear your opinion.

Firebird did it 5 years ago. They of course use only small part of C++
and they could do that because they takeover source code and they
started to clean a code.

Advantage of C++ is that it reduce lot of OO code written in C in
postgresql, but it is so big effort to do that without small gain. It
will increase number of bugs. Do not forget also that C++ compiler is
not so common (so good) on different platforms. If somebody interesting
in that yes but like a fork ( PostgreSQL++ :-).

Better idea is to start to use C99 in postgreSQL ;-).

Zdenek

> Advantage of C++ is that it reduce lot of OO code written in
> C in PostgreSQL, but it is so big effort to do that without
> small gain. It will increase number of bugs. Do not forget
> also that C++ compiler is not so common (so good) on
> different platforms. If somebody interesting in that yes but
> like a fork ( PostgreSQL++ :-).

Reducing OO code that is written in C is one of my major interests. After
some investigating myself it appears that having the codebase fully
(rewritten in C++ will have an impact on the performance. So I guess such an
effort will result the code being more C++ish and fully OO, being a mixture
in C with some OO taste.

> Better idea is to start to use C99 in PostgreSQL ;-).

I have not investigated this yet. But I am very interested to know what the
advantages would be to "upgrade" the code to C99 standards.

Regards,
Gevik
http://www.truesoftware.net/gevik/

Gevik Babakhani napsal(a):

>> Better idea is to start to use C99 in PostgreSQL ;-).
>
> I have not investigated this yet. But I am very interested to know what the
> advantages would be to "upgrade" the code to C99 standards.

I think replace macros with inline functions. It brings to ability to
monitor them for example by DTrace.

Zdenek

Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> Gevik Babakhani napsal(a):
>> I have not investigated this yet. But I am very interested to know what the
>> advantages would be to "upgrade" the code to C99 standards.

> I think replace macros with inline functions. It brings to ability to
> monitor them for example by DTrace.

C99's definition of inline functions really sucks --- it's awkward to
use, and essentially doesn't work at all for declaring inlines in header
files, which would be the main use if we wanted to replace macros with
inlines. I'm much happier using gcc's version of inline where we really
need it (which is not that many places anyway).

regards, tom lane

On 9/25/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> > Gevik Babakhani napsal(a):
>
> >> I have not investigated this yet. But I am very interested to know what the
> >> advantages would be to "upgrade" the code to C99 standards.
>
> > I think replace macros with inline functions. It brings to ability to
> > monitor them for example by DTrace.
>
>
> C99's definition of inline functions really sucks --- it's awkward to
> use, and essentially doesn't work at all for declaring inlines in header
> files, which would be the main use if we wanted to replace macros with
> inlines. I'm much happier using gcc's version of inline where we really
> need it (which is not that many places anyway).

AFAIK the problem was only with 'extern inline' which is different,
the 'static inline' which is the main replacement for macros,
should behave same?

+1 for C99

--
marko

Gevik Babakhani wrote:
>> Advantage of C++ is that it reduce lot of OO code written in
>> C in PostgreSQL, but it is so big effort to do that without
>> small gain. It will increase number of bugs. Do not forget
>> also that C++ compiler is not so common (so good) on
>> different platforms. If somebody interesting in that yes but
>> like a fork ( PostgreSQL++ :-).
>>
>
> Reducing OO code that is written in C is one of my major interests. After
> some investigating myself it appears that having the codebase fully
> (rewritten in C++ will have an impact on the performance. So I guess such an
> effort will result the code being more C++ish and fully OO, being a mixture
> in C with some OO taste.
>

Not sure what "reduce" means here. Is the following really a
*worthwhile* reduction?

Class* object = Class_new(...);
Class_method(object, ...);
Class_destroy(object);

Compared to:

Class *object = new Class(...);
object->method(...);
delete object;

Yes, this can sometimes be abbreviated by using stack-based objects:

Class object (...);
object.method(...);

Though, this limits capabilities in terms of automatic memory management
in terms of passing pointers to object around, or to using a memory area
that is cleaned up as a whole "in bulk" once it is no longer required.

STL can help, but it can also hinder.

I'm not convinced that a C++ PostgreSQL would be that much smaller
either in terms of source lines of code, or in terms of resulting binary
size. Also, it may not run faster. If the method calls are virtual, for
instance, and derived classes are used, each method call becomes one
more level of indirection.

>> Better idea is to start to use C99 in PostgreSQL ;-).
>>
>
> I have not investigated this yet. But I am very interested to know what the
> advantages would be to "upgrade" the code to C99 standards

The code might look a little bit cleaner, but other than that, I don't
see it running faster or being significantly smaller.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>

pgdev(at)xs4all(dot)nl ("Gevik Babakhani") writes:
>> Advantage of C++ is that it reduce lot of OO code written in
>> C in PostgreSQL, but it is so big effort to do that without
>> small gain. It will increase number of bugs. Do not forget
>> also that C++ compiler is not so common (so good) on
>> different platforms. If somebody interesting in that yes but
>> like a fork ( PostgreSQL++ :-).
>
> Reducing OO code that is written in C is one of my major
> interests. After some investigating myself it appears that having
> the codebase fully (rewritten in C++ will have an impact on the
> performance. So I guess such an effort will result the code being
> more C++ish and fully OO, being a mixture in C with some OO taste.

I'm not convinced that it would a good idea at all to make the system
"fully OO", nor that C++ would be a meaningful tool to use to that
end.

After all, C++ can certainly be used in decidedly non-OO ways. For
instance, STL is NOT an OO framework, and the author of STL, obviously
something of a fan of C++, characterizes OO as "almost as much of a
hoax as Artificial Intelligence."
<http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism>

I tend to agree with that characterization.

Further, C++ suffers from the same "not OO at its base" problem of
Java, which contributes complexity as well as hurting the "OO-ness" of
it."

>> Better idea is to start to use C99 in PostgreSQL ;-).
>
> I have not investigated this yet. But I am very interested to know
> what the advantages would be to "upgrade" the code to C99 standards.

It would give us heartburn on any platforms where the preferred
compiler doesn't grok C99, for sure.

As much as I'm ok with using GCC, it would seem unfortunate to force
people into using GCC everywhere, and preclude using other compilers.
(And actually, I'm more ambivalent about GCC than that; I'm not
totally happy with how GCC has gone, but that's another tale for
another day...)
--
(format nil "~S(at)~S" "cbbrowne" "acm.org")
http://linuxdatabases.info/info/linux.html
"NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't
in the coffin... It's wondering what the heck is sealing itself into a
wooden box 6 feet underground..." -- Jason McMullan

On Sep 25, 2008, at 5:50 PM, Chris Browne wrote:

> pgdev(at)xs4all(dot)nl ("Gevik Babakhani") writes:
>>> Advantage of C++ is that it reduce lot of OO code written in
>>> C in PostgreSQL, but it is so big effort to do that without
>>> small gain. It will increase number of bugs. Do not forget
>>> also that C++ compiler is not so common (so good) on
>>> different platforms. If somebody interesting in that yes but
>>> like a fork ( PostgreSQL++ :-).
>>
>> Reducing OO code that is written in C is one of my major
>> interests. After some investigating myself it appears that having
>> the codebase fully (rewritten in C++ will have an impact on the
>> performance. So I guess such an effort will result the code being
>> more C++ish and fully OO, being a mixture in C with some OO taste.
>
> I'm not convinced that it would a good idea at all to make the system
> "fully OO", nor that C++ would be a meaningful tool to use to that
> end.
>
> After all, C++ can certainly be used in decidedly non-OO ways. For
> instance, STL is NOT an OO framework, and the author of STL, obviously
> something of a fan of C++, characterizes OO as "almost as much of a
> hoax as Artificial Intelligence."
> <http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism>
>
> I tend to agree with that characterization.
>
> Further, C++ suffers from the same "not OO at its base" problem of
> Java, which contributes complexity as well as hurting the "OO-ness" of
> it."
>
>>> Better idea is to start to use C99 in PostgreSQL ;-).
>>
>> I have not investigated this yet. But I am very interested to know
>> what the advantages would be to "upgrade" the code to C99 standards.
>
> It would give us heartburn on any platforms where the preferred
> compiler doesn't grok C99, for sure.
>
> As much as I'm ok with using GCC, it would seem unfortunate to force
> people into using GCC everywhere, and preclude using other compilers.
> (And actually, I'm more ambivalent about GCC than that; I'm not
> totally happy with how GCC has gone, but that's another tale for
> another day...)

Speaking of language choice, no one said that _all_ the source code
would need to be rewritten. It would be nice, for example, if
PostgreSQL rewrote the current GUC system with a glue language like
Lua (which is also very C-like).

Cheers,
M

A.M. wrote:
>
>
> Speaking of language choice, no one said that _all_ the source code
> would need to be rewritten. It would be nice, for example, if
> PostgreSQL rewrote the current GUC system with a glue language like
> Lua (which is also very C-like).
>
>

No it wouldn't. All it would mean is that you'd need developers fluent
in both languages.

If this were a greenfields project we might well now make choices other
than those made in the past, but that doesn't mean we should constantly
revisit those decisions.

cheers

andrew

On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Speaking of language choice, no one said that _all_ the source code would
>> need to be rewritten. It would be nice, for example, if PostgreSQL rewrote
>> the current GUC system with a glue language like Lua (which is also very
>> C-like).
>
> No it wouldn't. All it would mean is that you'd need developers fluent in
> both languages.

Having done quite a bit of internals work with SAP DB (which is an
amalgamation of C, C++, and Pascal), I completely agree. The entire
system, if possible, should be in a single language.

--
Jonah H. Harris, Senior DBA
myYearbook.com

andrew(at)dunslane(dot)net (Andrew Dunstan) writes:
> A.M. wrote:
>> Speaking of language choice, no one said that _all_ the source code
>> would need to be rewritten. It would be nice, for example, if
>> PostgreSQL rewrote the current GUC system with a glue language like
>> Lua (which is also very C-like).
>>
> No it wouldn't. All it would mean is that you'd need developers
> fluent in both languages.

I expect it would be both a little better *and* a little worse than
that.

On the "better" side, I don't expect that, in this instance, there
would be terribly much need for anything but the shallowest
understanding of Lua. If this were all there was to it, I'd contend
that there's little to object to.

However, there's a pretty considerable "worse" side, namely that
developers would need to understand the API for interfacing between
the "bits of C" that are the Lua 'external interface' and how that
gets "plumbed" into PostgreSQL. *That's* got very little to do with
language, per se; it has to do with the implementation of the
language.
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/oses.html
"Real concurrency---in which one program actually continues to
function while you call up and use another---is more amazing but of
small use to the average person. How many programs do you have that
take more than a few seconds to perform any task?"
-- New York Times, 4/25/89

jonah(dot)harris(at)gmail(dot)com ("Jonah H. Harris") writes:
> On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Speaking of language choice, no one said that _all_ the source code would
>>> need to be rewritten. It would be nice, for example, if PostgreSQL rewrote
>>> the current GUC system with a glue language like Lua (which is also very
>>> C-like).
>>
>> No it wouldn't. All it would mean is that you'd need developers fluent in
>> both languages.
>
> Having done quite a bit of internals work with SAP DB (which is an
> amalgamation of C, C++, and Pascal), I completely agree. The entire
> system, if possible, should be in a single language.

Note that this actually *isn't* possible; PostgreSQL is implemented in
a number of languages already:
a) C, obviously
b) m4 and some autoconf macrology
c) GNU make
d) There's some awk
e) Shell script
f) Flex
g) Bison

And I'm not sure that's all there is :-).
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/lisp.html
If a hole in the street is a manhole, is a hole in a man a streethole?

Chris Browne wrote:
> jonah(dot)harris(at)gmail(dot)com ("Jonah H. Harris") writes:
>
>> On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>
>>>> Speaking of language choice, no one said that _all_ the source code would
>>>> need to be rewritten. It would be nice, for example, if PostgreSQL rewrote
>>>> the current GUC system with a glue language like Lua (which is also very
>>>> C-like).
>>>>
>>> No it wouldn't. All it would mean is that you'd need developers fluent in
>>> both languages.
>>>
>> Having done quite a bit of internals work with SAP DB (which is an
>> amalgamation of C, C++, and Pascal), I completely agree. The entire
>> system, if possible, should be in a single language.
>>
>
> Note that this actually *isn't* possible; PostgreSQL is implemented in
> a number of languages already:
> a) C, obviously
> b) m4 and some autoconf macrology
> c) GNU make
> d) There's some awk
> e) Shell script
> f) Flex
> g) Bison
>
> And I'm not sure that's all there is :-).
>

You are including build tools, which is a whole different topic. Knock
those out and you have C, flex and bison, the last two of which are in
fact preprocessors and have analogues for almost any target language we
might choose.

This whole debate is pretty pointless, ISTM.

cheers

andrew

Chris Browne wrote:
> jonah(dot)harris(at)gmail(dot)com ("Jonah H. Harris") writes:
>
>> Having done quite a bit of internals work with SAP DB (which is an
>> amalgamation of C, C++, and Pascal), I completely agree. The entire
>> system, if possible, should be in a single language.
>>
>
> Note that this actually *isn't* possible; PostgreSQL is implemented in
> a number of languages already:
> a) C, obviously
> b) m4 and some autoconf macrology
> c) GNU make
> d) There's some awk
> e) Shell script
> f) Flex
> g) Bison
>
> And I'm not sure that's all there is :-).
>

Agree on Andrew's point of "continuation of this thread is pointless" -
but not being very pointed, I'd point out that the various integrations
with PL/Perl, PL/Python, PL/Tcl, and PL/PgSQL means that PostgreSQL is
both intimate about the bindings between C and the language, and
knowledge about the languages themselves.

So, "all one language" is indeed unrealistic.

But, this thread has split. The first question was whether PostgreSQL
should be re-written in C++ or something else, where the answer seems to
be almost a universal "no". The second question is whether PostgreSQL
can be extended with pluggable languages, for which I think the answer
is already a yes. If some parts of PostgreSQL are not performance
bottlenecks, and they are extremely complicated to write in C, and very
easy to write in something else common and simple (I've never used LUA
myself?), I imagine it would be acceptable to the community.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>

On Sat, Sep 27, 2008 at 12:13 PM, Mark Mielke <mark(at)mark(dot)mielke(dot)cc> wrote:
> If
> some parts of PostgreSQL are not performance bottlenecks, and they are
> extremely complicated to write in C, and very easy to write in something
> else common and simple (I've never used LUA myself?), I imagine it would be
> acceptable to the community.

As long as they can expose their interfaces using the standard PG
function call interface, and use the documented SPI mechanism to talk
to the rest of the back end. Stuff that hooks into undocumented or
unstable parts of the code would be much less viable.

-Doug

2008/9/27 Douglas McNaught <doug(at)mcnaught(dot)org>:
> On Sat, Sep 27, 2008 at 12:13 PM, Mark Mielke <mark(at)mark(dot)mielke(dot)cc> wrote:
>> If
>> some parts of PostgreSQL are not performance bottlenecks, and they are
>> extremely complicated to write in C, and very easy to write in something
>> else common and simple (I've never used LUA myself?), I imagine it would be
>> acceptable to the community.
>
> As long as they can expose their interfaces using the standard PG
> function call interface, and use the documented SPI mechanism to talk
> to the rest of the back end. Stuff that hooks into undocumented or
> unstable parts of the code would be much less viable.
>
> -Doug
>
> --
> 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
>

I think that C is the best language for Postgresql. C++ has a little
thinks that make not good for performance.
Why people want to make more understable code touching the language?.
Simplify documentation for programmmers. Thats was the idea in the beggining.