Thread: 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, 19 Sep 2008 21:54:53 +0200 "Gevik Babakhani" <pgdev@xs4all.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
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, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev@xs4all.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
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@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.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@xs4all.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@postgresql.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@pgadmin.org> wrote: > On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev@xs4all.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@druid.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@xs4all.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@xs4all.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@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.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@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of > Jonah H. Harris > Sent: Friday, September 19, 2008 10:39 PM > To: Gevik Babakhani > Cc: Dave Page; PGSQL Hackers; > heikki.linnakangas@enterprisedb.com; jd@commandprompt.com > Subject: Re: [HACKERS] PostgreSQL future ideas > > On Fri, Sep 19, 2008 at 4:32 PM, Gevik Babakhani > <pgdev@xs4all.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@postgresql.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@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.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@xs4all.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
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
> 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@postgresql.org) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Gevik Babakhani wrote: <blockquote cite="mid:006201c91aa2$5c64bde0$0a01a8c0@gevmus" type="cite"><blockquote type="cite"><prewrap="">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, </pre></blockquote><pre wrap=""> 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. </pre></blockquote><br /> A major problem I have with this suggestionis that PostgreSQL would indeed be equivalent or better re-written in another language. All PostgreSQL benchmarkingand 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 inguaranteeing that you will see a 10 times or more drop in performance. Why? Because what is fast in Java is not the sameas what is fast in C. The design decisions would all need to be revisited, and the effect would be exactly as alreadysuggested - an immature design, competing against other mature designs.<br /><br /> From C to C++ is only a smallerleap in the sense that pieces of PostgreSQL could be migrated at a time. The result is still that an OO-modelled PostgreSQLwould be significantly different from a procedure-modelled PostgreSQL, and you would always be facing the compromiseof: 1) Should re-write this part to be OO? or 2) Should we leave it alone for now (and then, why bother using C++?).<br/><br /> Somebody working on a thesis or with thousands of hours of spare time and no inclination to work on anyother part, might prove that many of the PostgreSQL technologies port well to another language - but it is far more likelythat the result will be a bust.<br /><br /> I'd rather core developer effort was spent doing what they are doing today.<br/><br /> Cheers,<br /> mark<br /><pre class="moz-signature" cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
Joshua Drake wrote: > On Fri, 19 Sep 2008 23:01:15 +0200 > "Gevik Babakhani" <pgdev@xs4all.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@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.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.linnakangas@enterprisedb.com; > david@fetter.org; josh@agliodbs.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@postgresql.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@xs4all.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@pgadmin.org> wrote: > > On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev@xs4all.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@2ndQuadrant.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@druid.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@pgadmin.org> wrote: >> On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <pgdev@xs4all.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@2ndQuadrant.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@xs4all.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, andb) 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@cornell.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@momjian.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.Kotala@Sun.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@sss.pgh.pa.us> wrote: > Zdenek Kotala <Zdenek.Kotala@Sun.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: <blockquote cite="mid:002401c91ef4$16302fc0$0a01a8c0@gevmus" type="cite"><blockquote type="cite"><prewrap="">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++ :-). </pre></blockquote><pre wrap=""> 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. </pre></blockquote><br /> Not sure what "reduce" means here. Is the following really a *worthwhile*reduction?<br /><br /> Class* object = Class_new(...);<br /> Class_method(object, ...);<br /> Class_destroy(object);<br/><br /> Compared to:<br /><br /> Class *object = new Class(...);<br /> object->method(...);<br/> delete object;<br /><br /> Yes, this can sometimes be abbreviated by using stack-based objects:<br/><br /> Class object (...);<br /> object.method(...);<br /><br /> Though, this limits capabilities interms of automatic memory management in terms of passing pointers to object around, or to using a memory area that is cleanedup as a whole "in bulk" once it is no longer required.<br /><br /> STL can help, but it can also hinder.<br /><br/> I'm not convinced that a C++ PostgreSQL would be that much smaller either in terms of source lines of code, or interms of resulting binary size. Also, it may not run faster. If the method calls are virtual, for instance, and derivedclasses are used, each method call becomes one more level of indirection.<br /><br /><blockquote cite="mid:002401c91ef4$16302fc0$0a01a8c0@gevmus"type="cite"><pre wrap=""></pre><blockquote type="cite"><pre wrap="">Betteridea is to start to use C99 in PostgreSQL ;-). </pre></blockquote><pre wrap=""> 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</pre></blockquote><br /> The code might look a little bit cleaner,but other than that, I don't see it running faster or being significantly smaller.<br /><br /> Cheers,<br /> mark<br/><br /><pre class="moz-signature" cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
pgdev@xs4all.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@~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@xs4all.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@dunslane.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@dunslane.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.harris@gmail.com ("Jonah H. Harris") writes:
> On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew@dunslane.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, obviouslyb) m4 and some autoconf macrologyc) GNU maked) There's some awke) Shell
scriptf)Flexg) 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.harris@gmail.com ("Jonah H. Harris") writes:
>
>> On Fri, Sep 26, 2008 at 11:52 AM, Andrew Dunstan <andrew@dunslane.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: <blockquote cite="mid:87hc82mrna.fsf@dba2.int.libertyrms.com" type="cite"><pre wrap=""><a
class="moz-txt-link-abbreviated"href="mailto:jonah.harris@gmail.com">jonah.harris@gmail.com</a> ("Jonah H. Harris")
writes:</pre><blockquote type="cite"><pre wrap="">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. </pre></blockquote><pre wrap="">
Note that this actually *isn't* possible; PostgreSQL is implemented in
a number of languages already:a) C, obviouslyb) m4 and some autoconf macrologyc) GNU maked) There's some awke) Shell
scriptf)Flexg) Bison
And I'm not sure that's all there is :-). </pre></blockquote><br /> Agree on Andrew's point of "continuation of this
threadis 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
aboutthe languages themselves.<br /><br /> So, "all one language" is indeed unrealistic.<br /><br /> But, this thread
hassplit. The first question was whether PostgreSQL should be re-written in C++ or something else, where the answer
seemsto be almost a universal "no". The second question is whether PostgreSQL can be extended with pluggable languages,
forwhich I think the answer is already a yes. If some parts of PostgreSQL are not performance bottlenecks, and they are
extremelycomplicated 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.<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>
On Sat, Sep 27, 2008 at 12:13 PM, Mark Mielke <mark@mark.mielke.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