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

From Josh Berkus
Subject Re: pl/Ruby, deprecating plPython and Core
Date
Msg-id 200508161606.11105.josh@agliodbs.com
Whole thread Raw
In response to Re: pl/Ruby, deprecating plPython and Core  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: pl/Ruby, deprecating plPython and Core  (Tino Wildenhain <tino@wildenhain.de>)
Re: pl/Ruby, deprecating plPython and Core  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Mary Edie Meredith
Date:
Subject: Re: data on devel code perf dip
Next
From: Mark Wong
Date:
Subject: Re: data on devel code perf dip