Re: No PL/PHP ? Any reason?

> Obviously we need to improve our documentation. What led you to
> believe it does not exist?

This is my fault entirely. When I Googled for this, I flailed around with
fancy terms that didn't connect. And, as you pointed out, its not in the
core distibution or the foundry. But I didn't consider the product would be
logically called pl/php until I wrote this post!

>> * PHP is not as stable, mature, secure, or well designed as
>> Perl/Tcl/Python.

When I couldn't find any reference to pl/php I had assumed this was the
leading reason it "didn't exist".

>> Nobody uses pl/php.

I'm not a PHP developer (but after programmer, but my understanding is that
the PHP community is over-represented with HTML designers using PHP to
create dynamic content. What I have seen was lots of in-line HTML/PHP
programming with no understanding of seperating the presentation from the
business logic. But this is not PHP's fault.

However, it stands to reason that there ARE people writing good PHP code
with a seperation between the business/model and the presentation layer.
This code would represent the business process repository and could be
shared with other applications (especially non-PHP ones) either via a web
service or as a stored proc. Web services are fussy things, whereas if you
have a connection to a DB already, a stored proc is a simple thing.

Carlo

""Greg Sabino Mullane"" <greg@turnstep.com> wrote in message
news:41933015e64e0593a31f4e6cc30ee15a@biglumber.com...
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> Is there any technical obstacle to anyone creating PL/PHP? I am
>> cruious as to why it doesn't alreay exist.
>
> Obviously we need to improve our documentation. What led you to
> believe it does not exist? As pointed out downthread, it does
> exist (if not maintained).
>
>> 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.
>
> 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 in core
> * Not even in contrib or pgfoundry or github
> * It seems to suffer from a lot of configuration issues
> * Hard to find:
> ** First google hit on pl/php is projects.commandprompt.com/public/plphp
> ** Which simply says: Go here instead: https://redmine.commandprompt.com/
> ** Which stops you with a login and password page
> * The documentation is a mess (dead URLs, mislabelled sections)
> * PHP is not as stable, mature, secure, or well designed as
> Perl/Tcl/Python.
>  Which makes Postgres people less likely to consider it.
> * They chose backslash '\' as their namespace delimiter. Backslash!
>
> Okay, that last one isn't a major strike, but it's damn annoying (and
> indicative of the poor design of the language :)
>
> - --
> Greg Sabino Mullane greg@turnstep.com
> PGP Key: 0x14964AC8 201006220936
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -----BEGIN PGP SIGNATURE-----
>
> iEYEAREDAAYFAkwgv9MACgkQvJuQZxSWSsgULQCfUB7AtsvETYJAI7okRdCvSh3D
> d6AAnA+GfxpeUqGrXw0CMhB8mWNH0wSF
> =xLp+
> -----END PGP SIGNATURE-----
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>