Re: No PL/PHP ? Any reason?

Excerpts from Greg Sabino Mullane's message of mar jun 22 13:51:35 UTC 2010:

> > I mean, I love my Tcl support, and I know this is part of PG's
> > legacy... but Tcl and no PHP? I figure there's a tech reason for
> > this - the demand must be there! No?
>
> No, I'd say the demand is most definitely not there. I support a
> great number of clients, and pretty much everyone uses pl/pgsql,
> a great many use pl/perl, and a handful use pl/tcl or pl/python
> or pl/ruby. Nobody uses pl/php.

Hey, Robert Treat uses it -- he even gives talks about it, I hear!

> Some major strikes against it (consider these todo items for
> those who would like to see pl/php live again):
>
> * No trusted/untrusted versions

Not true, actually.

> * Not in core

Yeah.  It has been proposed and shot down several times by -core and
others.  The reason given is that you'd have to build PHP twice (or
something like that) -- there's a configure chicken-and-egg problem, or
something.  It is a fairly bad reason, but it's what we got.

> * Not even in contrib or pgfoundry or github

pgfoundry is such a paradise, yes, I'm sure everyone agrees.  As for
github, I don't think it existed back when PL/php started.  It's
currently hosted in Command Prompt's Redmine site.

Maybe we should have a pgfoundry web-only site that directed the
prospective user to the Redmine site ...

> * The documentation is a mess (dead URLs, mislabelled sections)

No surprise :-(  I hasn't been touched since moving from Trac.

> * PHP is not as stable, mature, secure, or well designed as Perl/Tcl/Python.
>   Which makes Postgres people less likely to consider it.

Absolutely true.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support