Re: No PL/PHP ? Any reason? - Mailing list pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Joshua D. Drake wrote:
>> * No trusted/untrusted versions
>
> This is false. There are both.

Ah, good news, glad I was misinformed. I'm curious, what
mechanism does it use for trusted?

>> * Not even in contrib or pgfoundry or github
> No. No reason to be.

Reason: easier to find. A github mirror is cheap (only costing a
few minutes of time) and very useful.

lvaro Herrera wrote:
> I fixed it when I saw Greg's note.

Wow, that's some quick service. Thanks Alvaro.

Carlo Stonebanks wrote:
>> 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!

Not to belabor the point, but what terms did you use? At the very least,
someone can wrote a blog post with such terms so that other people searching
for plphp can find it easier. Better, the Official Docs can have the
terms (if they are reasonable).

>> 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.

Keep in mind the context of my "nobody uses pl/php" was "none of my
Postgres clients uses pl/php". Certainly it is, and can be useful to people.

As far as separating the presentation from the business logic, it's ironic
that most large PHP programs and apps have now completely moved away from
the traditional inline HTML+PHP in one file which was (is?) touted as a
PHP strength (which indicates that perhaps it is PHP's fault). This new
separation is a good thing, because that inline junk is the wrong way to
do things except for the quickest and ugliest of hacks.

> 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.

Sure, but I'd argue that it's certainly more portable to write it in
plpgsql before using any procedural language, especially now that
it is enabled by default in the next version. :)

Thanks to everyone for staying calm and reasoned in this thread. I'll
have to try harder with my PHP baiting next time.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201007122337
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkw74IUACgkQvJuQZxSWSsgRhQCg6ivis6IEP//FqLVDNeTxIYp1
LugAmwTDeBWbZJcRhaDg75aWcwiKWWD5
=YM6B
-----END PGP SIGNATURE-----