Thread: pl/Ruby, deprecating plPython and Core
Hello, I have negotiated with the author of pl/Ruby to release plRuby under the PostgreSQL license. The reason I did this is the following: 1. I felt we needed a truly OO language in core. 2. plPython isn't really moving forward and has the whole trusted/untrusted issue. Now anyone who knows me, knows that I love Python which means this is not a language argument as much as a functionality argument. Ruby for good or bad is gaining a large following and has become a very active language in a short period of time. It can also be trusted and untrusted. I believe that unless plPython can either be fixed or is going to continue to move forward as a pl language that we should consider deprecating it and even removing it in 8.2 or 8.3. As far as a PL language plruby seems to have some really good stuff. Here is the docs: http://moulon.inra.fr/ruby/plruby.html What does everybody think? Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> I have negotiated with the author of pl/Ruby to release plRuby under the
> PostgreSQL license. The reason I did this is the following:
> 1. I felt we needed a truly OO language in core.
> 2. plPython isn't really moving forward and has the whole
> trusted/untrusted issue.
Hmm. I read this as
Problem: not enough hackers to maintain our PL languages.
Proposed solution: add more PL languages.
Somehow this doesn't seem quite right.
If pl/ruby is going to get into the core, it should be because of demand
for it based on its own merits. I don't think this has got anything to
do with pl/python.
regards, tom lane
> > Hmm. I read this as > > Problem: not enough hackers to maintain our PL languages. > > Proposed solution: add more PL languages. > > Somehow this doesn't seem quite right. Although I see your point, that actually wasn't my point. My point was that I felt we need a good well respected (and dare I say *hot*) new language that was truly OO and could be run as a trusted/untrusted pl language. > > If pl/ruby is going to get into the core, it should be because of demand > for it based on its own merits. I agree. > I don't think this has got anything to > do with pl/python. Not directly but indirectly it does because for me at least, what drove my negotiations was that plPython is an OO language that I enjoy but can't use the way I want. pl/Ruby is an OO language that i enjoy that I *CAN* use the way I want. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
I do think plruby would be a nice addition to core. I also assume this is for the 8.2 release, not 8.1. --------------------------------------------------------------------------- Joshua D. Drake wrote: > > > > Hmm. I read this as > > > > Problem: not enough hackers to maintain our PL languages. > > > > Proposed solution: add more PL languages. > > > > Somehow this doesn't seem quite right. > > Although I see your point, that actually wasn't my point. My point was > that I felt we need a good well respected (and dare I say *hot*) new > language that was truly OO and could be run as a trusted/untrusted pl > language. > > > > > If pl/ruby is going to get into the core, it should be because of demand > > for it based on its own merits. > > I agree. > > > I don't think this has got anything to > > do with pl/python. > > Not directly but indirectly it does because for me at least, what drove > my negotiations was that plPython is an OO language that I enjoy but > can't use the way I want. pl/Ruby is an OO language that i enjoy that I > *CAN* use the way I want. > > Sincerely, > > Joshua D. Drake > > > -- > Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 > PostgreSQL Replication, Consulting, Custom Programming, 24x7 support > Managed Services, Shared and Dedicated Hosting > Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > I do think plruby would be a nice addition to core. I also assume this > is for the 8.2 release, not 8.1. Yes that would be my assumption as well. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Bruce Momjian wrote: >I do think plruby would be a nice addition to core. > > Me too. It needs some work (didn't build out of the box for me against cvs tip). FYI, I have a backburner project to create PL/JS, which would a trusted-only language - JS could actually be quite a nice fit, and it's probably the most widely known scripting language because of the browser support. So much to do, so little time ... cheers andrew
Am Montag, den 15.08.2005, 10:30 -0700 schrieb Joshua D. Drake: > Hello, > > I have negotiated with the author of pl/Ruby to release plRuby under the > PostgreSQL license. The reason I did this is the following: > > 1. I felt we needed a truly OO language in core. > 2. plPython isn't really moving forward and has the whole > trusted/untrusted issue. > > Now anyone who knows me, knows that I love Python which means this is > not a language argument as much as a functionality argument. > > Ruby for good or bad is gaining a large following and has become a very > active language in a short period of time. It can also be trusted and > untrusted. > > I believe that unless plPython can either be fixed or is going to > continue to move forward as a pl language that we should consider > deprecating it and even removing it in 8.2 or 8.3. There is the ply, which is right now working better then pythonu (it has support for generators for example) See http://python.projects.postgresql.org/quick.html the author is currently also working on the trusted language issue. So maybe when the time comes, one option would be to replace pl/python with this one. > As far as a PL language plruby seems to have some really good stuff. > Here is the docs: > > http://moulon.inra.fr/ruby/plruby.html > > What does everybody think? > > Sincerely, > > Joshua D. Drake > > > > > >
On E, 2005-08-15 at 10:30 -0700, Joshua D. Drake wrote: > Hello, > > I have negotiated with the author of pl/Ruby to release plRuby under the > PostgreSQL license. Good! > The reason I did this is the following: > > 1. I felt we needed a truly OO language in core. > 2. plPython isn't really moving forward and has the whole > trusted/untrusted issue. Is there a sound reason to believe that pl/Ruby does not have the trusted/untrusted issue ? I mean it took some time for pl/python to reveal that it can't be run as a trusted language. > Now anyone who knows me, knows that I love Python which means this is > not a language argument as much as a functionality argument. > > Ruby for good or bad is gaining a large following and has become a very > active language in a short period of time. It can also be trusted and > untrusted. Both of these things could be said about Python when it was about the same age Ruby is now. > I believe that unless plPython can either be fixed Fixed how ? > or is going to continue to move forward as a pl language Why is "movin forward" needed ? > that we should consider deprecating it and even removing it in 8.2 or 8.3. This argument reminds me of the "let's rewrite postgresql in C++" proposal that comes up every few months. > As far as a PL language plruby seems to have some really good stuff. > Here is the docs: > > http://moulon.inra.fr/ruby/plruby.html > > What does everybody think? -- Hannu Krosing <hannu@skype.net>
Joshua D. Drake wrote: > Hello, > > I have negotiated with the author of pl/Ruby to release plRuby under the > PostgreSQL license. The reason I did this is the following: > > What does everybody think? > I think you should take a closer look at PL/Java for the following reasons: 1. The number of followers of the Java language is extremely high and increasing. 2. Oracle and DB2 offers Java as a procedural language. You make transisitions easy. 3. There's a SQL standard for the mapping between the SQL and Java language. 4. Middle-tier code is often written in Java and can often be moved to functions and stored procedures without a rewrite. 5. PL/Java already provide both trusted and untrusted language handlers. 6. PL/Java has a community of over 70 members and increasing. 7. PL/Java has no license issue. 8. The author of PL/Java would be happy to maintain it in core. Regards, Thomas Hallgren
On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote: > Hello, > > I have negotiated with the author of pl/Ruby to release plRuby > under the PostgreSQL license. The reason I did this is the following: > > 1. I felt we needed a truly OO language in core. Why ? Are you truly going to write huge OO functions inside the db ? If not why do you need OO ? This looks to me to be just another syntax, what can you do in plruby that you can't do in plpgsql, or plsh, or pltcl, or pl<name> ? > 2. plPython isn't really moving forward and has the whole trusted/ > untrusted issue. > > Now anyone who knows me, knows that I love Python which means this > is not a language argument as much as a functionality argument. > > Ruby for good or bad is gaining a large following and has become a > very active language in a short period of time. It can also be > trusted and untrusted. > > I believe that unless plPython can either be fixed or is going to > continue to move forward as a pl language that we should consider > deprecating it and even removing it in 8.2 or 8.3. > > As far as a PL language plruby seems to have some really good > stuff. Here is the docs: > > http://moulon.inra.fr/ruby/plruby.html > > What does everybody think? > > Sincerely, > > Joshua D. Drake > > > > > > > -- > Your PostgreSQL solutions company - Command Prompt, Inc. > 1.800.492.2240 > PostgreSQL Replication, Consulting, Custom Programming, 24x7 support > Managed Services, Shared and Dedicated Hosting > Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > >
Dave Cramer wrote: > > On 15-Aug-05, at 1:30 PM, Joshua D. Drake wrote: > >> Hello, >> >> I have negotiated with the author of pl/Ruby to release plRuby under >> the PostgreSQL license. The reason I did this is the following: >> >> 1. I felt we needed a truly OO language in core. > > Why ? Are you truly going to write huge OO functions inside the db ? > If not why do you need OO ? > > This looks to me to be just another syntax, what can you do in plruby > that you can't do in plpgsql, or plsh, or pltcl, or pl<name> ? > I have actually seen quite significant serverside program libs. But in any case, having support for many server-side languages, OO or not, is a good thing, IMNSHO. It lets people write in what they are comfortable and familiar with. That's a selling point. If we follow the line that it's all just syntactic difference then we should just support one trusted and one untrusted language. That would be a pity. cheers andrew
Folks, > I think you should take a closer look at PL/Java for the following reasons: Hmmm, this brings up a good point. If we're going to consider PL/Ruby for main distro in 8.2, should we not consider PL/Java as well? -- Josh Berkus Aglio Database Solutions San Francisco
> Is there a sound reason to believe that pl/Ruby does not have the > trusted/untrusted issue ? Sure... it hasn't been found. We can play the it "might have" or "might not have" game all day long but it won't get us anywhere. Today, and yesterday pl/Ruby can be run trust/untrusted, pl/python can not. >>Ruby for good or bad is gaining a large following and has become a very >>active language in a short period of time. It can also be trusted and >>untrusted. > > > Both of these things could be said about Python when it was about the > same age Ruby is now. But they can't be said about Python now. Again I love Python but I can't use it the way I want to in the database. >>I believe that unless plPython can either be fixed > > > Fixed how ? Be able to be trusted. > > >>or is going to continue to move forward as a pl language > > > Why is "movin forward" needed ? Why do we need air to breathe? It is all about usability. The plPython feature set it quickly becoming obsolete by the other language that are in and not in core. Heck plPHP as scary as that is can do more. >> >>that we should consider deprecating it and even removing it in 8.2 or 8.3. > > > This argument reminds me of the "let's rewrite postgresql in C++" > proposal that comes up every few months. Your kidding right? I am not suggesting anything remotely close to that insane argument. All I am saying is that unless plPython can be made to be trust I think it should be deprecated. And no, doing a follow up with "Well, plC can't be trusted" isn't going to work. C is a completely different beast then the other pl languages. In replacement or addition to, I think that plRuby would be a good choice. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
> I think you should take a closer look at PL/Java for the following reasons: > > 1. The number of followers of the Java language is extremely high and > increasing. > 2. Oracle and DB2 offers Java as a procedural language. You make > transisitions easy. > 3. There's a SQL standard for the mapping between the SQL and Java > language. > 4. Middle-tier code is often written in Java and can often be moved to > functions and stored procedures without a rewrite. > 5. PL/Java already provide both trusted and untrusted language handlers. > 6. PL/Java has a community of over 70 members and increasing. > 7. PL/Java has no license issue. > 8. The author of PL/Java would be happy to maintain it in core. These are all very good reasons. I would honestly have to know more about how PL/Java works to make a decision. Sincerely, Joshua D. Drake > > Regards, > Thomas Hallgren > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Josh Berkus wrote: > Folks, > > >>I think you should take a closer look at PL/Java for the following reasons: > > > Hmmm, this brings up a good point. If we're going to consider PL/Ruby for > main distro in 8.2, should we not consider PL/Java as well? There is one strong reason other than that, I have zero objection to the idea. Most distributions of Linux (yes I know that there is more than Linux out there) don't ship with Java. They ship with a wanna be, but couldn't be in the next 2 years thing call Gcj. Sincerely, Joshua D. Drake > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, Aug 16, 2005 at 09:19:28AM -0700, Joshua D. Drake wrote: > Josh Berkus wrote: > >Folks, > > > > > >>I think you should take a closer look at PL/Java for the following > >>reasons: > > > > > >Hmmm, this brings up a good point. If we're going to consider > >PL/Ruby for main distro in 8.2, should we not consider PL/Java as > >well? > > There is one strong reason other than that, I have zero objection to > the idea. > > Most distributions of Linux (yes I know that there is more than > Linux out there) don't ship with Java. They ship with a wanna be, > but couldn't be in the next 2 years thing call Gcj. That's true. Then again, not everything comes with the right version of Python, Tcl, etc. What I'm saying is that a thing can be available in core and depend on libraries that you have to make sure are there before getting it running. If it makes any difference, +1 both on PL/J(ava) and PL/Ruby. On a very closely related note, what's the latest on the integration of PL/Java and PL/J? Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
Well, if we are going to consider pljava for the main distribution, then we should consider pl-j for inclusion as well. Dave On 16-Aug-05, at 11:53 AM, Josh Berkus wrote: > Folks, > > >> I think you should take a closer look at PL/Java for the following >> reasons: >> > > Hmmm, this brings up a good point. If we're going to consider PL/ > Ruby for > main distro in 8.2, should we not consider PL/Java as well? > > -- > Josh Berkus > Aglio Database Solutions > San Francisco > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that > your > message can get through to the mailing list cleanly > >
On 8/16/05, Joshua D. Drake <jd@commandprompt.com> wrote: > Sure... it hasn't been found. We can play the it "might have" or "might > not have" game all day long but it won't get us anywhere. Today, and > yesterday pl/Ruby can be run trust/untrusted, pl/python can not. > > Both of these things could be said about Python when it was about the > > same age Ruby is now. > > But they can't be said about Python now. Again I love Python but I can't > use it the way I want to in the database. > > >>I believe that unless plPython can either be fixed > > > > > > Fixed how ? > > Be able to be trusted. Really a lot of your points seem either to be appealing to the fad appeal of Ruby or misinformation about Python. It's silliness. The inclusion of pl/ruby should be considered independently of pl/python, they are separate matters. I promise that the aggregate work required for all coders who know Python to switch to ruby is far far greater than the work required to fix the issues with pl/python. :) I'd like to propose a more useful goal for consideration: PostgreSQL users should be able to use whatever language they write their frontend in to write their PL code. This doesn't mean it would be reasonable to include everything under the sun in the main distro, just as Linux distros don't normally ship ADA or Haskall compilers. But rather, any PL language which meets a certain level of capability (and yes, I'd propose having trusted support as being one of those requirements in languages where it makes sense) and has a sufficiently large user-base that we can reasonably expect it to be well supported should either be included in the main distro, or at least in a side-car PostgreSQL-PL package if driven there due to licensing concerns. Obviously there are costs in maintaining many PLs, but at the same time it doesn't really make sense to say that we're going to include PL/bar, and PL/baz but not PL/foo if all have comparable abilities and userbases. I see there being two rational paths, 1) support only one (or perhaps two where one is C and the other is something with trusted support) PL and claim that developers need to learn this PL in addition to what they write their frontends in. or 2) support a wealth of PLs with the intention of allowing developers to use the same language for their frontends as their database PL code. .... Any other position creates silly arguments, like replacing PL/Python with PL/Ruby. In terms of PostgreSQL's competitiveness in the marketplace of databases, my position would serve well: Other databases will have a more difficult time providing broad PL support, since PG already has a good head start there and joe-random application developer who doesn't care what database he uses will feel a lot more comfortable when he knows he can use the same language he's comfortable with for both front and back end support.
Joshua, There's some material that explains the inner workings on the gborg.postgresql.org/project/pljava site. Beyond that (and trying it out of course), I'd be more then happy to answer any questions. Regards, Thomas Hallgren Joshua D. Drake wrote: > >> I think you should take a closer look at PL/Java for the following >> reasons: >> >> 1. The number of followers of the Java language is extremely high and >> increasing. >> 2. Oracle and DB2 offers Java as a procedural language. You make >> transisitions easy. >> 3. There's a SQL standard for the mapping between the SQL and Java >> language. >> 4. Middle-tier code is often written in Java and can often be moved >> to functions and stored procedures without a rewrite. >> 5. PL/Java already provide both trusted and untrusted language handlers. >> 6. PL/Java has a community of over 70 members and increasing. >> 7. PL/Java has no license issue. >> 8. The author of PL/Java would be happy to maintain it in core. > > > These are all very good reasons. I would honestly have to know more > about how PL/Java works to make a decision. > > Sincerely, > > Joshua D. Drake > > > >> >> Regards, >> Thomas Hallgren >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly > > >
Dave Cramer wrote: > Well, if we are going to consider pljava for the main distribution, > then we should consider pl-j for inclusion as well. I believe we should consider both but only include 1. Sincerely, Joshua D. Drake > > Dave > On 16-Aug-05, at 11:53 AM, Josh Berkus wrote: > >> Folks, >> >> >>> I think you should take a closer look at PL/Java for the following >>> reasons: >>> >> >> Hmmm, this brings up a good point. If we're going to consider PL/ >> Ruby for >> main distro in 8.2, should we not consider PL/Java as well? >> >> -- >> Josh Berkus >> Aglio Database Solutions >> San Francisco >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly >> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
David Fetter wrote: >On a very closely related note, what's the latest on the integration >of PL/Java and PL/J? > > Last time I spoke to Laszlo and Dave about this, we discussed the following solution: - PL/Java should be profiled as a "tight Java integration", i.e. Java executes in the same VM as the backend. - PL/J should be profiled as a generic and language agnostic way of executing out-of-process calls. The PL/J framework can be used to integrate with other virtual VM's then Java (such as Mono for instance). This makes PL/Java and PL/J to completely different products and both producs have its own motivation. In addition we concluded that: - In order to maximize the outcome of our efforts and avoid head-on competition, PL/Java should _not_ enter the "loose Java integration" scene (i.e. remote JVM) and PL/J should _not_ enter the "tight Java integration" scene. - An effort must be made to make the PostgreSQL "Java as a procedural language" user experience as compatible as possible between PL/Java and a PL/J solution that uses a remote Java VM. - A new project was spawned (see http://j4sql.codehaus.org) where the PL/Java and PL/J teams make a joint effort to create an abstraction layer that allows a developer to write stored procedures and functions in a database independent way. Regards, Thomas Hallgren
On Tue, Aug 16, 2005 at 01:17:27PM -0400, Gregory Maxwell wrote: > On 8/16/05, Joshua D. Drake <jd@commandprompt.com> wrote: > > Sure... it hasn't been found. We can play the it "might have" or > > "might not have" game all day long but it won't get us anywhere. > > Today, and yesterday pl/Ruby can be run trust/untrusted, pl/python > > can not. > > > Both of these things could be said about Python when it was > > > about the same age Ruby is now. > > > > But they can't be said about Python now. Again I love Python but I > > can't use it the way I want to in the database. > > > > >>I believe that unless plPython can either be fixed > > > > > > > > > Fixed how ? > > > > Be able to be trusted. > > Really a lot of your points seem either to be appealing to the fad > appeal of Ruby or misinformation about Python. It's silliness. It's not. In PL/parlance, "trusted" means "prevented from ever opening a filehandle or a socket," and PL/PythonU is called PL/Python*U* (U for *un*trusted) because it cannot be so prevented. If somebody has figured out a way to make a PL/Python (without the U), that's great, but nothing has happened on this front in a couple of years, and Guido said that it was a problem with the language that he wasn't going to fix. > The inclusion of pl/ruby should be considered independently of > pl/python, they are separate matters. Not entirely. There are limited resources available for maintaining PLs. > I promise that the aggregate work required for all coders who know > Python to switch to ruby is far far greater than the work required > to fix the issues with pl/python. :) Are you certain? See above in re: what Guido had to say. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
Joshua D. Drake wrote: > Most distributions of Linux (yes I know that there is more than Linux > out there) don't ship with Java. They ship with a wanna be, but couldn't > be in the next 2 years thing call Gcj. > Gcj is OK with PL/Java, albeit slower then the more common JVM's from Sun, IBM, or BEA. Unfortunately, Gcj's security implementation is not complete and that results in that the PL/Java + Gcj combination has the same issue that PL/Python has. It can't be trusted. PL/Java relies on standard java security to provide support for the "trusted" handler. At present, it doesn't function correctly using Gcj. I've asked the Gcj team when they think they will have this and the reply that they hope to have it sometime 2005. Regards, Thomas Hallgren
On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote: > If somebody has figured out a way to make a PL/Python (without the U), > that's great, but nothing has happened on this front in a couple of > years, and Guido said that it was a problem with the language that he > wasn't going to fix. Could you provide a reference to that? -- marko
On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote: > On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote: > > If somebody has figured out a way to make a PL/Python (without the > > U), that's great, but nothing has happened on this front in a > > couple of years, and Guido said that it was a problem with the > > language that he wasn't going to fix. > > Could you provide a reference to that? Here's the word from Guido http://archives.postgresql.org/pgsql-hackers/2003-05/msg00687.php and the followup from Tom Lane http://archives.postgresql.org/pgsql-hackers/2003-05/msg00652.php Hope this helps. :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
On T, 2005-08-16 at 09:14 -0700, Joshua D. Drake wrote: > > Is there a sound reason to believe that pl/Ruby does not have the > > trusted/untrusted issue ? > > Sure... it hasn't been found. "It hasn't been found" is a really weak reason for any security assumption, even for a programming language. It must be a feature designed in, or at least proved to some extent of research (like java). > We can play the it "might have" or "might > not have" game all day long but it won't get us anywhere. Today, and > yesterday pl/Ruby can be run trust/untrusted, pl/python can not. Otoh most of my trusted language needs are met by plpgsql. I use pl/python mostly where I *need* the untrusted features - linking to external modules, opening files, sendine email, ... > >>Ruby for good or bad is gaining a large following and has become a very > >>active language in a short period of time. It can also be trusted and > >>untrusted. > > > > > > Both of these things could be said about Python when it was about the > > same age Ruby is now. > > But they can't be said about Python now. :) How about : Python has gained a large following over a long period of time and has been a well established and widely used language for a long time meaning that most of its security related features can be assumed to be known ? > Again I love Python but I can't use it the way I want to in the database. > > >>I believe that unless plPython can either be fixed > > > > > > Fixed how ? > > Be able to be trusted. use jython inside of pl/java ;) > >>or is going to continue to move forward as a pl language > > > > Why is "movin forward" needed ? > > Why do we need air to breathe? It is all about usability. The plPython > feature set it quickly becoming obsolete by the other language that are > in and not in core. Heck plPHP as scary as that is can do more. What exact fetures you mean that you would miss in (hypothetical) untrusted python which can do in pl/Ruby or pl/PHP ? > >>that we should consider deprecating it and even removing it in 8.2 or 8.3. > > > > > > This argument reminds me of the "let's rewrite postgresql in C++" > > proposal that comes up every few months. > > Your kidding right? I am not suggesting anything remotely close to that > insane argument. All I am saying is that unless plPython can be made to > be trust I think it should be deprecated. Maybe we should just spell out the difference of pl and pl/U languages in even bigger letters ? It is not that untrusted languages will eat your data, just that you can do some db superuser level things with them if you are allowed to create them, even if you are not superuser yourself. > And no, doing a follow up with "Well, plC can't be trusted" isn't going > to work. C is a completely different beast then the other pl languages. How different? Actually I mostly use plpython as a way to avoid writing my pl functions in C. I get 98% of capabilities of plC with 10% of coding. And if you are really keen on getting trusted plC, you can use any of the free C interpreters as a starting point for that. > In replacement or addition to, I think that plRuby would be a good choice. No argument against that, but unless Ruby will have all the extra modules python has gathered along the years (and preferrably python syntax :) ), I strongly object against "deprecating it and even removing it in 8.2 or 8.3". -- Hannu Krosing <hannu@skype.net>
On 8/16/05, David Fetter <david@fetter.org> wrote: > It's not. In PL/parlance, "trusted" means "prevented from ever > opening a filehandle or a socket," and PL/PythonU is called > PL/Python*U* (U for *un*trusted) because it cannot be so prevented. > > If somebody has figured out a way to make a PL/Python (without the U), > that's great, but nothing has happened on this front in a couple of > years, and Guido said that it was a problem with the language that he > wasn't going to fix. It's not a problem in the *language*, it's a problem in the implementation. There are other implementations of python, including one inside the JavaVM. It's also one which could be worked around with the existing python implementation by completely sandboxing the process running python (i.e. via seccomp in linux for example). Yes, it's a problem, yes it should be fixed. But it is BS to claim that python fundamentally has a problem and needs to be removed because of it, just as much as it would be BS to claim that ruby should forbidden because it permits the same sort of unmaintainable syntax that has plagued perl for years. :)
On Tue, Aug 16, 2005 at 05:09:24PM -0400, Gregory Maxwell wrote: > On 8/16/05, David Fetter <david@fetter.org> wrote: > > It's not. In PL/parlance, "trusted" means "prevented from ever > > opening a filehandle or a socket," and PL/PythonU is called > > PL/Python*U* (U for *un*trusted) because it cannot be so > > prevented. > > > > If somebody has figured out a way to make a PL/Python (without the > > U), that's great, but nothing has happened on this front in a > > couple of years, and Guido said that it was a problem with the > > language that he wasn't going to fix. > > It's not a problem in the *language*, it's a problem in the > implementation. There are other implementations of python, including > one inside the JavaVM. Great! We're all looking forward to your patch which implements PL/Python as you've suggested. :) > Yes, it's a problem, yes it should be fixed. But it is BS to claim > that python fundamentally has a problem and needs to be removed > because of it, Python has other fundamental problems as far as I'm concerned ;) > just as much as it would be BS to claim that ruby should forbidden > because it permits the same sort of unmaintainable syntax that has > plagued perl for years. :) As with an automatic weapon, Perl absolutely *requires* discipline to use properly. Unlike an automatic weapon, Perl is perfectly OK to use day-to-day in civilian life :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote: > As with an automatic weapon, Perl absolutely *requires* discipline to > use properly. Unlike an automatic weapon, Perl is perfectly OK to use > day-to-day in civilian life :) What on earth would be the proper use of an automatic weapon? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
Alvaro Herrera wrote: > On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote: > > >>As with an automatic weapon, Perl absolutely *requires* discipline to >>use properly. Unlike an automatic weapon, Perl is perfectly OK to use >>day-to-day in civilian life :) > > > What on earth would be the proper use of an automatic weapon? You obviously don't live in the US. ;) Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Alvaro Herrera said: > On Tue, Aug 16, 2005 at 02:14:46PM -0700, David Fetter wrote: > >> As with an automatic weapon, Perl absolutely *requires* discipline to >> use properly. Unlike an automatic weapon, Perl is perfectly OK to use >> day-to-day in civilian life :) > > What on earth would be the proper use of an automatic weapon? > and in any case, let's not have language wars. You like/don't like language foo? Good. We support your choice. Do / don't use language foo. cheers andrew
This seems to have descended into a "my programming language is better than your programming language" war, which has ceased to be interesting, much less illuminating to the problem at hand. There are two questions, I perceive, critical to making decisions about what goes into the core. While I'm not a contributing developer, I've worked with PostgreSQL since it was still Stonebraker's child and still use Postquel, and have rolled it inot a lot of production situations, so I'm going to speak from that perspective. 1) More isn't better. 2) What the *MARKET* cares about is PL/PGSQL and PL/Java. I have the utmost detestful view of Java, but that's what it is. I don't write my stored-procedures in Java, I write them in PL/PGSQL because it is familiar to those who have to maintain the database, which in my situation is often not who is maintaining the "front end" code which many other languages are so happy for. Personally, I think pulling PL/Java in, and throwing the rest out, is a great idea. Let them mature seperately, and keep the perenial language wars out of the core. What is in the core is a decision made on a couple of points: 1) What helps Postgresql in the "market," such that it is. 2) What would the core team be willing to take ownership of because of #1, even if the existing supports disappeared. As someone who has been writing in Python since 1994, I like the language, and we could have all sorts of discussions about language idioms and safety, and the perception of each, but neither have anything to do with the decision at hand. Axes should be put away, and people should decide what is critical to the market perception of the database, and as much as I hate to admit it, Java is 1000x more important than Ruby, Perl, Python and Tcl combined, when it comes to SELLING the use of Postgresql in a formal organization. Outside that scenerio, why does it matter? Open source "geeks" will download whatever to make it work, and bundling and non bundling have nothing to do with their "decision" process. Chris -- | Christopher Petrilli | petrilli@gmail.com
People:
How about we draft some criteria for inclusion of a PL in the main distro?
Suggestions:
1) The PL must be "stable" (that is, not capable of crashing the backend)
2) The PL must be buildable only using --with-{lang} and createlang
(assuming that the user has the correct libraries)
3) There must be a regression test included, which tests both creating the
lang and creating+executing a small function in it.
4) The PL must have at least one maintainer who subscribes to
pgsql-hackers.
5) It must be possible to build the PL without changing the licensing of
PostgreSQL (this excludes PL/R, unfortunately).
Controversial Criterion:
6) The PL should be buildable in "trusted" mode. (I vote no on this one)
I, myself, do not think that either popularity or inclusion of the language
in Linux distros should be a criterion. If PL/Haskell or PL/Smalltalk
catches on with *our* community it should be good enough for us. Heck,
were it not for the licensing and build issues, I'd be advocating strongly
fro PL/R.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
> There are two questions, I perceive, critical to making decisions > about what goes into the core. While I'm not a contributing developer, > I've worked with PostgreSQL since it was still Stonebraker's child and > still use Postquel, and have rolled it inot a lot of production > situations, so I'm going to speak from that perspective. > > 1) More isn't better. Actually it can be, if more equates to more choice of quality product that allows programmers to use the environment they are most comfortable with. > > 2) What the *MARKET* cares about is PL/PGSQL and PL/Java. Who's Market? The Oracle market? O.k.... The PostgreSQL Market? Not likely. Yes plJava is a big player, but I doubt nearly as many people use it as say plPerlNG. Is plJava important? You bet. It makes all those sweaty types that yell "Developers, Developers, Developers" while running around on stage like a monkey... oh wait that is .Net. Is there a difference? Sorry I digress, the point is, Ruby has a HUGE following in Asia and is growing very, very quickly in the US. If it wasn't, Oreilly wouldn't be annoyed that several other publishers had beat them to the punch in publishing books on it. > I have the utmost detestful view of Java, but that's what it is. I > don't write my stored-procedures in Java, I write them in PL/PGSQL > because it is familiar to those who have to maintain the database, No it is familiar to those who maintain or have maintained Oracle. I personally detest plPgsql and will only use it because a lot of times it is faster than the other langes. > Personally, I think pulling PL/Java in, and throwing the rest out, is > a great idea. Let them mature seperately, and keep the perenial > language wars out of the core. What is in the core is a decision made > on a couple of points: I don't think you would get anyone to vote for that. 1. It is extreme 2. There are a lot of developers, I would say most with PostgreSQL that don't use or want to use Java. > 1) What helps Postgresql in the "market," such that it is. Choice, to allow developers to use the tools they want and know how to use. That includes plJava and plRuby, and plPHP etc... > > 2) What would the core team be willing to take ownership of because of > #1, even if the existing supports disappeared. Well I think there is a minimal chance of that. > > As someone who has been writing in Python since 1994, I like the > language, and we could have all sorts of discussions about language > idioms and safety, and the perception of each, but neither have > anything to do with the decision at hand. Actually they do, directly because Python can't be trusted from the PostgreSQL point of view. > Axes should be put away, and people should decide what is critical to > the market perception of the database, and as much as I hate to admit > it, Java is 1000x more important than Ruby, Perl, Python and Tcl Really? Give me numbers. Where are your sources? What statistics show this? Again I am not suggestion that pljava isn't important but your arguments seem more based on what was on the cover of Java magazine than actual reality of what people are using to code. Do you realize the number of Perl, Python and Ruby programmers and programs there are out there? Now include PHP and just a touch of C and Java is a drop in the bucket. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
>>> As with an automatic weapon, Perl absolutely *requires* discipline to >>> use properly. Unlike an automatic weapon, Perl is perfectly OK to use >>> day-to-day in civilian life :) >> >> >> >> What on earth would be the proper use of an automatic weapon? > > > You obviously don't live in the US. Yeah, "hunting"...
Josh Berkus schrieb:
> People:
>
> How about we draft some criteria for inclusion of a PL in the main distro?
>
> Suggestions:
>
> 1) The PL must be "stable" (that is, not capable of crashing the backend)
> 2) The PL must be buildable only using --with-{lang} and createlang
> (assuming that the user has the correct libraries)
> 3) There must be a regression test included, which tests both creating the
> lang and creating+executing a small function in it.
> 4) The PL must have at least one maintainer who subscribes to
> pgsql-hackers.
> 5) It must be possible to build the PL without changing the licensing of
> PostgreSQL (this excludes PL/R, unfortunately).
>
> Controversial Criterion:
> 6) The PL should be buildable in "trusted" mode. (I vote no on this one)
>
> I, myself, do not think that either popularity or inclusion of the language
> in Linux distros should be a criterion. If PL/Haskell or PL/Smalltalk
> catches on with *our* community it should be good enough for us. Heck,
> were it not for the licensing and build issues, I'd be advocating strongly
> fro PL/R.
+1 on all of this from me
David Fetter wrote: > On Tue, Aug 16, 2005 at 01:17:27PM -0400, Gregory Maxwell wrote: > >>I promise that the aggregate work required for all coders who know >>Python to switch to ruby is far far greater than the work required >>to fix the issues with pl/python. :) > > Are you certain? See above in re: what Guido had to say. > I find the whole argument that, lack of an untrusted version of the PL means it should be deprecated, crazy. There are plenty of situations where you don't care that the PL is untrusted. Joe
Josh Berkus wrote:
> People:
>
> How about we draft some criteria for inclusion of a PL in the main distro?
>
> Suggestions:
>
> 1) The PL must be "stable" (that is, not capable of crashing the backend)
Check. (well, a more humble statement is perhaps to say that any bug
that would cause a crash would be considered critical and get immediate
attention. Shit happens).
> 2) The PL must be buildable only using --with-{lang} and createlang
> (assuming that the user has the correct libraries)
PL/Java builds using the pgx stuff and needs no further config then an
environment setting that appoints the JVM. Adding a --with-java is
probably very easy once the code is included in the distro (I say
probably because I have no idea of how to do it).
> 3) There must be a regression test included, which tests both creating the
> lang and creating+executing a small function in it.
PL/Java includes a bunch of tests today. I guess you have some test
harness where such tests can be plugged in?
> 4) The PL must have at least one maintainer who subscribes to
> pgsql-hackers.
Check. And if more people wants to step in then I'm all for it.
> 5) It must be possible to build the PL without changing the licensing of
> PostgreSQL (this excludes PL/R, unfortunately).
Check.
>
> Controversial Criterion:
> 6) The PL should be buildable in "trusted" mode. (I vote no on this one)
Check. PL/Java always enables two language handlers, java and javaU.
Nevertheless, my vote would also be to exclude this criteria. The
important thing is that the user of an untrusted PL knows the implications.
I'd like to add one other criteria that PL/Java is lacking today but I
think every PL should have.
7) The PL language handler(s) must be created with an associated
VALIDATOR function.
> I, myself, do not think that either popularity or inclusion of the language
> in Linux distros should be a criterion. If PL/Haskell or PL/Smalltalk
> catches on with *our* community it should be good enough for us. Heck,
> were it not for the licensing and build issues, I'd be advocating strongly
> fro PL/R.
>
I agree. Even if Java is very popular in general it is less so within
this community and that is what counts. A criterion that I think would
be valid though (and also likely relate to popularity) is of course if a
sponsor made a commitment and secured the continued evolution and
maintenance of the PL.
There's also another point that has not been brought up yet. Most PL's
use code that's inlined in the SQL function body. Java (like C) cannot
do that. So there are two categories of PL's; the ones that allow inline
code and the ones that require modules that contain the code to be
loaded somehow. PL/Java belongs to the latter. Not everyone is in favor
of that approach.
Regards,
Thomas Hallgren
On Tue, Aug 16, 2005 at 01:46:26PM -0700, David Fetter wrote: > On Tue, Aug 16, 2005 at 11:39:04PM +0300, Marko Kreen wrote: > > On Tue, Aug 16, 2005 at 10:38:37AM -0700, David Fetter wrote: > > > If somebody has figured out a way to make a PL/Python (without the > > > U), that's great, but nothing has happened on this front in a > > > couple of years, and Guido said that it was a problem with the > > > language that he wasn't going to fix. > > > > Could you provide a reference to that? > > Here's the word from Guido > > http://archives.postgresql.org/pgsql-hackers/2003-05/msg00687.php Thanks. Although this does not seem as definite as you said it be, rather current Python architecture makes it harder than it should be. Btw, at least Zope guys have 'figured a out a way': http://marc.theaimsgroup.com/?l=python-dev&m=107666724918647&w=2 Only problem with their implementation is that they haven't updated it yet for Python 2.4. -- marko
As there are two java procedural languages which are available for postgreSQL Josh asked for an explanation as to their differences. They are quite similar in that both of them run the function in a java vm, and are pre-compiled. Neither attempt to compile the code. The biggest difference is how they connect to the java VM. PL/Java uses Java Native Interfaces (JNI) and does a direct call into the java VM from the language handler. PL-J uses a network protocol to connect to a java VM. There are advantages and disadvantages to both approaches. + JNI is simpler, doesn't require a protocol, or an application container to manage the User Defined Functions - JNI requires that the vm runs on the server machine, and a separate vm be instantiated for every connection that calls a function. This is mitigated somewhat in java 1.5, by sharing data,however this may or may not be a Sun only feature ( does anyone know ); either way a separate vm is required for each connection. - startup time for the vm on the first call for the connection. - Possible ( not as likely any more ) for the java VM to take the server down. Using a network protocol such as a pl-j does has the following ( basically the opposite of the JNI (dis)advantages ) + The java VM does not have to run on the server. + Only one vm per server - More complex, requires a micro kernel application server to manage the UDF's currently http://loom.codehaus.org/ Dave
Dave Cramer wrote: > As there are two java procedural languages which are available for > postgreSQL Josh asked for an explanation as to their differences. > They are quite similar in that both of them run the function in a > java vm, and are pre-compiled. Neither attempt to compile the code. > > The biggest difference is how they connect to the java VM. > > PL/Java uses Java Native Interfaces (JNI) and does a direct call into > the java VM from the language handler. > > PL-J uses a network protocol to connect to a java VM. > > > There are advantages and disadvantages to both approaches. > > + JNI is simpler, doesn't require a protocol, or an application > container to manage the User Defined Functions > - JNI requires that the vm runs on the server machine, and a separate > vm be instantiated for every connection that calls a function. > This is mitigated somewhat in java 1.5, by sharing data, however > this may or may not be a Sun only feature ( does anyone know ); > either way a separate vm is required for each connection. > - startup time for the vm on the first call for the connection. > - Possible ( not as likely any more ) for the java VM to take the > server down. > > Using a network protocol such as a pl-j does has the following ( > basically the opposite of the JNI (dis)advantages ) > > + The java VM does not have to run on the server. > + Only one vm per server > - More complex, requires a micro kernel application server to manage > the UDF's currently http://loom.codehaus.org/ > > That's a pretty good explanation and ought to be published more widely. It's almost a pity that we couldn't have one project with a server setting saying how we want it to run. I seem to recall hearing of a Sun gadget in the works that would let a process connect to a running VM and load classes and run them. I have been a bit out of it on Java lately - does anyone know of such a thing, or is my memory failing again? cheers andrew
Andrew Dunstan wrote: > > > Dave Cramer wrote: > >> As there are two java procedural languages which are available for >> postgreSQL Josh asked for an explanation as to their differences. >> They are quite similar in that both of them run the function in a >> java vm, and are pre-compiled. Neither attempt to compile the code. >> >> The biggest difference is how they connect to the java VM. >> >> PL/Java uses Java Native Interfaces (JNI) and does a direct call into >> the java VM from the language handler. >> >> PL-J uses a network protocol to connect to a java VM. >> >> >> There are advantages and disadvantages to both approaches. >> >> + JNI is simpler, doesn't require a protocol, or an application >> container to manage the User Defined Functions >> - JNI requires that the vm runs on the server machine, and a separate >> vm be instantiated for every connection that calls a function. >> This is mitigated somewhat in java 1.5, by sharing data, however >> this may or may not be a Sun only feature ( does anyone know ); >> either way a separate vm is required for each connection. >> - startup time for the vm on the first call for the connection. >> - Possible ( not as likely any more ) for the java VM to take the >> server down. >> >> Using a network protocol such as a pl-j does has the following ( >> basically the opposite of the JNI (dis)advantages ) >> >> + The java VM does not have to run on the server. >> + Only one vm per server >> - More complex, requires a micro kernel application server to manage >> the UDF's currently http://loom.codehaus.org/ >> >> I think Dave miss a couple of important points. 1. Speed. One major reason for moving code from the middle tier down to the database is that you want to execute the code close to the actual persistence mechanisms in order to minimize network traffic and maximize throughput. 2. A growing percentage of db-clients utilize some kind of connection pool (an overwelming amount of the java clients certanly do), which minimizes the problem with startup times. 3. Transaction visiblity. A function that in turn issues new SQL calls must do that wihtin the scope of the caller transaction. A remote process must hence call back into it's caller. PL/Java has its own JDBC driver that interacts directly with SPI. 4. Isolation. Using separate VM's, instabilities in the VM can only affect one single connecton. One VM can be debugged or monitored without affecting the others. No data can be inadvertidely moved between connections, etc. I try to shed more light on the pros and cons here: http://gborg.postgresql.org/project/pljava/genpage.php?jni_rationale > That's a pretty good explanation and ought to be published more widely. > It's almost a pity that we couldn't have one project with a server > setting saying how we want it to run. > There are a couple of reasons that make me a bit reluctant to join the projects: PL/Java have no dependencies at all besides a Java Runtime Environment (or GCJ). PL/J reqires a fair amount of other modules just to compile. PL/Java is at release 1.1 and have a community of users. To my knowledge, PL/J has not reached its first release yet. PL/Java and PL/J use completely different approaches and share almost no code. The code that we do share (public interfaces, manly for trigger management) is published at the Maven repository at ibiblio.org. I think it's better to keep the two projects separate. But I also think that it is extremely important that we ensure that the user experience is similar for both projects so that there's nothing to prevent a server setting that decides which one to use provided both are present. Kind regards, Thomas Hallgren
> I find the whole argument that, lack of an untrusted version of the PL > means it should be deprecated, crazy. There are plenty of situations > where you don't care that the PL is untrusted. Yes you are absolutely correct. However my argument was more than that. It contained: The fact that it was only untrusted Not moving forward. plPython is basically in a static state, I can't do (AFAIK) in plPython today that I couldn't do 2 years ago. PostgreSQL is moving forward at an increasing rate. The pl languages that are in core should at least try to keep up with the feature set. Also there is the maintainability perspective. I may write a one time function in plpython because python is my prefered language. I would not however use it as my primary language for procedures because it can't be trusted. Believe me, if plPython could be trusted I would be all over anyone who suggested deprecating it. Python is my preferred language. Sincerely, Joshua D. Drake > > Joe -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On 17-Aug-05, at 12:40 PM, Thomas Hallgren wrote: > Andrew Dunstan wrote: > >> Dave Cramer wrote: >> >>> As there are two java procedural languages which are available >>> for postgreSQL Josh asked for an explanation as to their >>> differences. >>> They are quite similar in that both of them run the function in >>> a java vm, and are pre-compiled. Neither attempt to compile the >>> code. >>> >>> The biggest difference is how they connect to the java VM. >>> >>> PL/Java uses Java Native Interfaces (JNI) and does a direct call >>> into the java VM from the language handler. >>> >>> PL-J uses a network protocol to connect to a java VM. >>> >>> >>> There are advantages and disadvantages to both approaches. >>> >>> + JNI is simpler, doesn't require a protocol, or an application >>> container to manage the User Defined Functions >>> - JNI requires that the vm runs on the server machine, and a >>> separate vm be instantiated for every connection that calls a >>> function. >>> This is mitigated somewhat in java 1.5, by sharing data, >>> however this may or may not be a Sun only feature ( does anyone >>> know ); >>> either way a separate vm is required for each connection. >>> - startup time for the vm on the first call for the connection. >>> - Possible ( not as likely any more ) for the java VM to take >>> the server down. >>> >>> Using a network protocol such as a pl-j does has the following >>> ( basically the opposite of the JNI (dis)advantages ) >>> >>> + The java VM does not have to run on the server. >>> + Only one vm per server >>> - More complex, requires a micro kernel application server to >>> manage the UDF's currently http://loom.codehaus.org/ >>> >>> >>> > I think Dave miss a couple of important points. > > 1. Speed. One major reason for moving code from the middle tier > down to the database is that you want to execute the code close to > the actual persistence mechanisms in order to minimize network > traffic and maximize throughput. I think until there are actual benchmarks, there are too many variables here to suggest one is faster than the other. The overhead of having multiple java vm's is not easily estimated. Even with a connection pool, consider the memory footprint of even 10 java VM's > > 2. A growing percentage of db-clients utilize some kind of > connection pool (an overwelming amount of the java clients certanly > do), which minimizes the problem with startup times. > > 3. Transaction visiblity. A function that in turn issues new SQL > calls must do that wihtin the scope of the caller transaction. A > remote process must hence call back into it's caller. PL/Java has > its own JDBC driver that interacts directly with SPI. PL-J maintains transaction visibility, it has it's own JDBC driver as well. The protocol between the language handler and the java portion is based upon the FE/BE protocol which made it easy to use pg's JDBC driver with some modification. > > 4. Isolation. Using separate VM's, instabilities in the VM can only > affect one single connecton. One VM can be debugged or monitored > without affecting the others. No data can be inadvertidely moved > between connections, etc. Loom deals with data integrity, debugging would have to be done by a remote debug connection and can connect to any thread. > > I try to shed more light on the pros and cons here: http:// > gborg.postgresql.org/project/pljava/genpage.php?jni_rationale > > >> That's a pretty good explanation and ought to be published more >> widely. It's almost a pity that we couldn't have one project with >> a server setting saying how we want it to run. >> > There are a couple of reasons that make me a bit reluctant to join > the projects: > > PL/Java have no dependencies at all besides a Java Runtime > Environment (or GCJ). PL/J reqires a fair amount of other modules > just to compile. PL-J requires one other module, which the build environment will fetch automatically to compile. > > PL/Java is at release 1.1 and have a community of users. To my > knowledge, PL/J has not reached its first release yet. > > PL/Java and PL/J use completely different approaches and share > almost no code. The code that we do share (public interfaces, manly > for trigger management) is published at the Maven repository at > ibiblio.org. > > I think it's better to keep the two projects separate. But I also > think that it is extremely important that we ensure that the user > experience is similar for both projects so that there's nothing to > prevent a server setting that decides which one to use provided > both are present. > > Kind regards, > Thomas Hallgren > > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > >
Thomas, Dave, I did *NOT* want to start another discussion about what approach is superior. Keep in mind that for us non-Java geeks most of your argument is pure ancient Greek. What I wanted to establish is: potentially, we will have two Java PLs with Postgres. If we do, we need to have a clear documentation section explaining why there are two and why a user might want to choose one or the other. This explanation should be comprehensible to a neophyte Java programmer and even to a DBA who doesn't do Java but has to install it. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Dave, Some responses inline. As a reaction to what Josh just wrote - "Keep in mind that for us non-Java geeks most of your argument is pure ancient Greek" - I'll try to talk in generic terms from now on and not mention Java since the difference between our solutions have nothing whatsoever to do with Java. Java is what we have in common :-) I'm all in favor of writing a good descriptive chapter that explains the differences between the solutions. Dave Cramer wrote: >> 1. Speed. One major reason for moving code from the middle tier down >> to the database is that you want to execute the code close to the >> actual persistence mechanisms in order to minimize network traffic >> and maximize throughput. > > I think until there are actual benchmarks, there are too many > variables here to suggest one is faster than the other. The overhead > of having multiple java vm's is not easily estimated. Even with a > connection pool, consider the memory footprint of even 10 java VM's I think it would be a very good idea to jointly create a test bench where we can measure performance. Not only could we make just comparisons between our solutions, we could also use it to improve on them. The results could also be included in the documentation section that Josh requests and serve as facts for decision making. The reason I brougth the speed issue up is that I felt that you mentioned PL/Java's two weakest points (memory consumption and startup time) but failed to mention the weakest point of PL-J (slow inter-process calls). A side-note: The footprint of 10 VM's doesn't scare me that much. A modern VM that doesn't run an app-server and no GUI doesn't consume that much (they sure used to though). On my Windows-XP box, one VM typically consumes about 20-40Mb virtual memory and 6-13Mb real memory. I currently have 50 VM's running simultaniously without problems. >> 3. Transaction visiblity. A function that in turn issues new SQL >> calls must do that wihtin the scope of the caller transaction. A >> remote process must hence call back into it's caller. PL/Java has >> its own JDBC driver that interacts directly with SPI. > > PL-J maintains transaction visibility, it has it's own JDBC driver as > well. The protocol between the language handler and the java portion > is based upon the FE/BE protocol which made it easy to use pg's JDBC > driver with some modification. Ok, Bad heading. My point was that for each call you make from the backend to the VM, the VM must make a call back to the caller, receive the results, and then propagate those results back to the caller that actually had them in the first place. That's a lot of unnecessary network traffic. The relevance of this should of course also be tested in the test bench. > PL-J requires one other module, which the build environment will > fetch automatically to compile. PL-J Requires a specific build environment. Thats one dependency. In addition there are 6 dependencies listed in its project descriptor. The problems that arise when you depend heavily on other modules are not just related to how they are obtained. You need to keep track of bugs that concern you, their fixes and release versions. You want to know about new features that you might want to use (while still maintaining backward compatibility of course), and you must watch out for inter-component dependencies and version conflicts that might arise every time you bump a version of something. There might be licensing issues, etc. When PL/Java was designed I made a serious effort to avoid all that. Hence my concern. Regards, Thomas Hallgren
Joshua D. Drake wrote: > >> I find the whole argument that, lack of an untrusted version of the PL >> means it should be deprecated, crazy. There are plenty of situations >> where you don't care that the PL is untrusted. > > > Yes you are absolutely correct. However my argument was more than that. Right. I was responding to the entire thread that was headed in the direction of saying that just because a language doe not have a trusted PL version, it should be removed. As others have said, I find myself using PL/pgSQL when I need trusted, and frequently use other languages when I need untrusted. And in most of my experience, I don't even care if the language is trusted or untrusted. There are plenty of use cases for both. Joe