Re: pl/Ruby, deprecating plPython and Core

On 8/16/05, Joshua D. Drake <jd(at)commandprompt(dot)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.