Thread

pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-15T17:30:45Z

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/

Re: pl/Ruby, deprecating plPython and Core

Tom Lane <tgl@sss.pgh.pa.us> — 2005-08-15T18:24:52Z

"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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-15T19:11:52Z

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

Re: pl/Ruby, deprecating plPython and Core

Bruce Momjian <pgman@candle.pha.pa.us> — 2005-08-15T19:20:15Z

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, Pennsylvania 19073

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-15T19:28:26Z

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/

Re: pl/Ruby, deprecating plPython and Core

Andrew Dunstan <andrew@dunslane.net> — 2005-08-15T20:14:23Z

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

Re: pl/Ruby, deprecating plPython and Core

Tino Wildenhain <tino@wildenhain.de> — 2005-08-15T20:42:56Z

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

Re: pl/Ruby, deprecating plPython and Core

Hannu Krosing <hannu@skype.net> — 2005-08-16T05:04:25Z

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>

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-16T05:40:00Z

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

Re: pl/Ruby, deprecating plPython and Core

Dave Cramer <pg@fastcrypt.com> — 2005-08-16T12:08:07Z

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

Re: pl/Ruby, deprecating plPython and Core

Andrew Dunstan <andrew@dunslane.net> — 2005-08-16T13:42:04Z

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

Re: pl/Ruby, deprecating plPython and Core

Josh Berkus <josh@agliodbs.com> — 2005-08-16T15:53:22Z

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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T16:14:12Z

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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T16:16:00Z

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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T16:19:28Z

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/

Re: pl/Ruby, deprecating plPython and Core

David Fetter <david@fetter.org> — 2005-08-16T16:32:16Z

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!

Re: pl/Ruby, deprecating plPython and Core

Dave Cramer <pg@fastcrypt.com> — 2005-08-16T17:10:02Z

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

Re: pl/Ruby, deprecating plPython and Core

Gregory Maxwell <gmaxwell@gmail.com> — 2005-08-16T17:17:27Z

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.

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-16T17:18:28Z

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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T17:22:56Z

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/

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-16T17:38:13Z

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

Re: pl/Ruby, deprecating plPython and Core

David Fetter <david@fetter.org> — 2005-08-16T17:38:37Z

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!

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-16T17:56:16Z

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

Re: pl/Ruby, deprecating plPython and Core

Marko Kreen <marko@l-t.ee> — 2005-08-16T20:39:04Z

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

Re: pl/Ruby, deprecating plPython and Core

David Fetter <david@fetter.org> — 2005-08-16T20:46:26Z

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!

Re: pl/Ruby, deprecating plPython and Core

Hannu Krosing <hannu@skype.net> — 2005-08-16T20:47:21Z

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>

Re: pl/Ruby, deprecating plPython and Core

Gregory Maxwell <gmaxwell@gmail.com> — 2005-08-16T21:09:24Z

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. :)

Re: pl/Ruby, deprecating plPython and Core

David Fetter <david@fetter.org> — 2005-08-16T21:14:46Z

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!

Re: pl/Ruby, deprecating plPython and Core

Andrew Dunstan <andrew@dunslane.net> — 2005-08-16T21:19:27Z

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

Re: pl/Ruby, deprecating plPython and Core

Alvaro Herrera <alvherre@alvh.no-ip.org> — 2005-08-16T21:42:45Z

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)

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T22:00:30Z

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/

Re: pl/Ruby, deprecating plPython and Core

Christopher Petrilli <petrilli@gmail.com> — 2005-08-16T22:23:40Z

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

Re: pl/Ruby, deprecating plPython and Core

Josh Berkus <josh@agliodbs.com> — 2005-08-16T23:06:10Z

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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-16T23:07:41Z

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

Re: pl/Ruby, deprecating plPython and Core

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2005-08-17T02:56:42Z

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

Re: pl/Ruby, deprecating plPython and Core

Tino Wildenhain <tino@wildenhain.de> — 2005-08-17T06:16:47Z

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

Re: pl/Ruby, deprecating plPython and Core

Joe Conway <mail@joeconway.com> — 2005-08-17T07:50:13Z

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

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-17T08:05:09Z

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

Re: pl/Ruby, deprecating plPython and Core

Marko Kreen <marko@l-t.ee> — 2005-08-17T10:25:08Z

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

Re: pl/Ruby, deprecating plPython and Core

Dave Cramer <pg@fastcrypt.com> — 2005-08-17T13:28:38Z

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

Re: pl/Ruby, deprecating plPython and Core

Andrew Dunstan <andrew@dunslane.net> — 2005-08-17T14:00:57Z


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

Re: pl/Ruby, deprecating plPython and Core

Joshua D. Drake <jd@commandprompt.com> — 2005-08-17T16:33:59Z

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

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-17T16:40:07Z

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

Re: pl/Ruby, deprecating plPython and Core

Dave Cramer <pg@fastcrypt.com> — 2005-08-17T18:32:58Z

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

Re: pl/Ruby, deprecating plPython and Core

Josh Berkus <josh@agliodbs.com> — 2005-08-17T20:14:01Z

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

Re: pl/Ruby, deprecating plPython and Core

Thomas Hallgren <thhal@mailblocks.com> — 2005-08-17T21:54:31Z

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

Re: pl/Ruby, deprecating plPython and Core

Joe Conway <mail@joeconway.com> — 2005-08-18T00:42:51Z

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