pl/Ruby, deprecating plPython and Core

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

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.

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

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:

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:

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/