Re: pl/Ruby, deprecating plPython and Core - Mailing list pgsql-hackers

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>