Re: [HACKERS] plPHP in core? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: [HACKERS] plPHP in core?
Date
Msg-id 1112712064.20921.11.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: [HACKERS] plPHP in core?  (Paul Tillotson <pntil@shentel.net>)
Responses Re: [HACKERS] plPHP in core?  (Russ Brown <pickscrape@gmail.com>)
List pgsql-general
On Mon, 2005-04-04 at 19:52, Paul Tillotson wrote:
> Joshua D. Drake wrote:
>
> >
> >> Honestly, I think if we're going to spend time worrying about languages
> >> as features then we should be doing more to advertise the fact that
> >> perl/PHP/python/ruby/etc programmers can program in the database in
> >> their native language.
> >>
> > I agree with you completely.
> >
> Although others may like the ability to choose their PL language, I
> would like it better if the important developers would pick one (and
> only one) high-level scripting language (i.e., one that has built in
> hashes, dynamic variable scoping, and the like), and declare it to be
> the "sanctioned" language.  (Others could still work on optional
> languages as they do now.)
>
> Thus, even though I know very little about Ruby or TCL, I would gladly
> learn one of those if I knew that plruby or pltcl did all the stuff that
> a pl should (wasn't missing functionality such as writing triggers,
> set-returning functions), was efficiently implemented, was well tested,
> and was installed by default.

There are some points in this idea I like, and some I don't.

I completely understand the point that no one wants to pick a PL, only
to get halfway through learning it when you find out that it doesn't do
one or two things you really want your PL to do, and having to learn
another PL.

However, given the constantly changing landscape of PLs, with things
like the recent issue of Python being safe, then not being safe, then
being safe again, it's hard to say that one particular PL or subset of
PLs is (are) the blessed one(s).

Now, if there were no features that PL/PGSQL left out, then it would be
the one true PL.  But there are a few things it's just not as good at as
tcl or a few other PLs.

What I would much prefer is a matrix that shows all the features a PL
should / could have, and which PLs have those features, which features
are currently being implemented, who maintains them if they are
maintained, if they aren't maintained, etc..  So that when it comes time
to choose one, you can make an informed decision ahead of time.

Then, when a PL was deemed to be stable, fully featured, and well
maintained, it could possibly be included in the base distro as a mature
tool.

I don't see a reason to artificially limit the choices to one and only
one language, but do see the reasons to limit it to the mature and fully
implemented ones.

Then again, I'd much rather have them be completely modular so you just
download the pl packages of your choice and install them yourself.

pgsql-general by date:

Previous
From: David Fetter
Date:
Subject: Re: PL/PERL: raise notice, exception ?
Next
From: Scott Marlowe
Date:
Subject: Re: [Fwd: [webmaster] in Search of free hosting with