Thread: No PL/PHP ? Any reason?

Is there any technical obstacle to anyone creating PL/PHP? I am cruious as
to why it doesn't alreay exist. 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?

On Tue, Jun 22, 2010 at 1:28 PM, Carlo Stonebanks <stonec.register@sympatico.ca> wrote:

Is there any technical obstacle to anyone creating PL/PHP? I am cruious as to why it doesn't alreay exist. 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?

There is one already: https://public.commandprompt.com/projects/plphp

On Mon, Jun 21, 2010 at 9:55 PM, Devrim GUNDUZ <devrim@gunduz.org> wrote:
> 22.Haz.2010 tarihinde 06:43 saatinde, Shoaib Mir <shoaibmir@gmail.com>
> şunları yazdı:
>
> On Tue, Jun 22, 2010 at 1:28 PM, Carlo Stonebanks
> <stonec.register@sympatico.ca> wrote:
>>
>> Is there any technical obstacle to anyone creating PL/PHP? I am cruious as
>> to why it doesn't alreay exist. 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?
>>
>
> There is one already: https://public.commandprompt.com/projects/plphp
>
> IIRC, it does not compile against newer PostgreSQL releases and it is not
> under development right now.

I recall talking to the guys at command prompt and apparently
something in the php runtime makes it unsuitable for pl deployment.
Been a while, I don't remember what, just that the php folks had no
interest in fixing it.

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

There's this one: https://www.commandprompt.com/community/plphp/

-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Carlo Stonebanks
Sent: Tuesday, 22 June 2010 1:29 PM
To: pgsql-general@postgresql.org
Subject: [GENERAL] No PL/PHP ? Any reason?

Is there any technical obstacle to anyone creating PL/PHP? I am cruious as
to why it doesn't alreay exist. 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?


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

On Tue, 2010-06-22 at 13:51 +0000, Greg Sabino Mullane wrote:
> -----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).

It is maintained. We address items as they come in. Is it currently
being developed for new features? No.

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

People do use it but it certainly doesn't have the usage of pl/python or
pl/perl.

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

This is false. There are both.

> * Not in core

True. Check the archives there were long discussions as to why it won't
work. Basically the build path of PHP isn't really compatible with the
build path of PostgreSQL.

> * Not even in contrib or pgfoundry or github

No. No reason to be.

> * 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/

No it doesn't (but I am not sure when this was fixed).

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

Yeah we probably need to update it from the migration from Trac.

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

No it is just more popular, more widely used and has a larger community.

(Oh: And remember, I am a python guy)

Joshua D. Drake



--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

Excerpts from Joshua D. Drake's message of mar jun 22 12:16:11 -0400 2010:
> On Tue, 2010-06-22 at 13:51 +0000, Greg Sabino Mullane wrote:

> > * 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/
>
> No it doesn't (but I am not sure when this was fixed).

I fixed it when I saw Greg's note.

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

On Tue, 2010-06-22 at 13:51 +0000, Greg Sabino Mullane wrote:
> -----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).

It is maintained. We address items as they come in. Is it currently
being developed for new features? No.

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

People do use it but it certainly doesn't have the usage of pl/python or
pl/perl.

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

This is false. There are both.

> * Not in core

True. Check the archives there were long discussions as to why it won't
work. Basically the build path of PHP isn't really compatible with the
build path of PostgreSQL.

> * Not even in contrib or pgfoundry or github

No. No reason to be.

> * 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/

No it doesn't (but I am not sure when this was fixed).

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

Yeah we probably need to update it from the migration from Trac.

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

No it is just more popular, more widely used and has a larger community.

(Oh: And remember, I am a python guy)

Joshua D. Drake



--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On 23/06/10 02:16, Joshua D. Drake wrote:
> On Tue, 2010-06-22 at 13:51 +0000, Greg Sabino Mullane wrote:
>
>>> 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).
>>
> It is maintained. We address items as they come in. Is it currently
> being developed for new features? No.
>
>> * Not in core
>>
> True. Check the archives there were long discussions as to why it won't
> work. Basically the build path of PHP isn't really compatible with the
> build path of PostgreSQL.
>
>
>> * PHP is not as stable, mature, secure, or well designed as Perl/Tcl/Python.
>>
> No it is just more popular, more widely used and has a larger community.
>
> (Oh: And remember, I am a python guy)
>
>

The biggest obstacle to more widespread use is packaging.  There are no
installable packages for pl/php.  It would make a world of difference
for it to have packages hosted as part of the yum repository.  It would
be better for me if there were debian/ubuntu packages as well.  It would
be easy for people to install which means it would be easy for people to
use.  It's a lot of work to build from source, especially with the
strange dependency stuff.  Part of the reason I haven't built from
source is because that isn't easy.  For adoption in the enterprise, the
compile from source requirement kills using pl/php as an option.  And I
have developers who'd like to use it.  If you try to argue to build
something from source in my work, not a chance.  But there is at least a
chance of installing a package from a different repository.  It's seen
as much easier to back out and manage particularly if you want support
from your vendor.

At one point I did try to make a debian package for pl/php.  I wasn't
experienced enough at either debian packaging or the pl/php build
procedure to make it all hang together.  I still firmly believe there
would be more adoption if it was packaged.

Regards

Russell

Excerpts from Devrim GUNDUZ's message of lun jun 21 23:55:41 -0400 2010:

> IIRC, it does not compile against newer PostgreSQL releases and it is
> not under development right now.

It compiles with 9.0 just fine (and earlier releases too, though I
didn't bother to test anything earlier than 8.2).  It failed to compile
with PHP 5.3, but I fixed that yesterday.  It now works with both 5.2
and 5.3; it should work with 5.1 too (it used to) but I didn't test
that, because it's unsupported.

There hasn't been much development lately, but it works.  Some newer
features of Postgres functions are, of course, not supported, but stuff
like named params, triggers and SRF are there.

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

On Wed, Jun 23, 2010 at 3:31 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Devrim GUNDUZ's message of lun jun 21 23:55:41 -0400 2010:
>
>> IIRC, it does not compile against newer PostgreSQL releases and it is
>> not under development right now.
>
> It compiles with 9.0 just fine (and earlier releases too, though I
> didn't bother to test anything earlier than 8.2).  It failed to compile
> with PHP 5.3, but I fixed that yesterday.  It now works with both 5.2
> and 5.3; it should work with 5.1 too (it used to) but I didn't test
> that, because it's unsupported.

Thanks for making it work for 5.3, we're just migrating to it this
summer, so it would be nice to have it available as a pl for some of
our developers as well.

On Jun 22, 2010, at 1:08 AM, Scott Marlowe wrote:

> I recall talking to the guys at command prompt and apparently
> something in the php runtime makes it unsuitable for pl deployment.


Any chance that the Parrot runtime could be used for PHP and other languages? I read that some folks are working on
PL/Parrot.I'd really like to have PHP and Lisp for PL languages :). 



John DeSoi, Ph.D.

On Wed, 2010-06-23 at 17:17 -0400, John DeSoi wrote:
> On Jun 22, 2010, at 1:08 AM, Scott Marlowe wrote:
>
> > I recall talking to the guys at command prompt and apparently
> > something in the php runtime makes it unsuitable for pl deployment.
>
>
> Any chance that the Parrot runtime could be used for PHP and other languages? I read that some folks are working on
PL/Parrot.I'd really like to have PHP and Lisp for PL languages :). 

http://plscheme.projects.postgresql.org/

Not exactly lisp, but....

>
>
>
> John DeSoi, Ph.D.
>
>
>
>
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On Wed, 2010-06-23 at 17:17 -0400, John DeSoi wrote:
> On Jun 22, 2010, at 1:08 AM, Scott Marlowe wrote:
>
> > I recall talking to the guys at command prompt and apparently
> > something in the php runtime makes it unsuitable for pl deployment.
>
>
> Any chance that the Parrot runtime could be used for PHP and other languages? I read that some folks are working on
PL/Parrot.I'd really like to have PHP and Lisp for PL languages :). 

http://plscheme.projects.postgresql.org/

Not exactly lisp, but....

>
>
>
> John DeSoi, Ph.D.
>
>
>
>
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

"Joshua D. Drake" <jd@commandprompt.com> writes:
>> Any chance that the Parrot runtime could be used for PHP and other languages? I read that some folks are working on
PL/Parrot.I'd really like to have PHP and Lisp for PL languages :). 
>
> http://plscheme.projects.postgresql.org/
>
> Not exactly lisp, but....

But it's using gnu guile, version 2 of which should support multiple
languages. It's expected to get released with scheme, javascript and lua
support last I checked, and maybe with Emacs Lisp support too.

  http://www.gnu.org/software/soc-projects/ideas-2010.html#guile

So who want to open bets for Parrot versus Guile2? More seriously
though, it could be that our best bet to have pl/js is plscheme and
guile2.

Regards,
--
dim

On Wed, Jun 23, 2010 at 05:17:13PM -0400, John DeSoi wrote:
> Any chance that the Parrot runtime could be used for PHP and other
> languages? I read that some folks are working on PL/Parrot. I'd really like
> to have PHP and Lisp for PL languages :).

Some folks are definitely working on it. The idea is that any language running
on Parrot will be usable with PL/Parrot. Whether that pans out in real life is
an open question, probably, but it's part of the plan.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

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

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

On Tue, 2010-07-13 at 03:42 +0000, Greg Sabino Mullane wrote:
> -----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?

I would have to defer to Alvaro on that one.

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

Yes, we have been looking into github rather aggressively. I would
expect something like that to happen.


JD

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

Excerpts from Joshua D. Drake's message of mar jul 13 00:00:07 -0400 2010:
> On Tue, 2010-07-13 at 03:42 +0000, Greg Sabino Mullane wrote:
> > -----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?
>
> I would have to defer to Alvaro on that one.

PHP's "safe mode"
http://www.php.net/manual/en/features.safe-mode.php

... which, now I realize, has been deprecated ...

On Tue, 2010-07-13 at 03:42 +0000, Greg Sabino Mullane wrote:
> -----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?

I would have to defer to Alvaro on that one.

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

Yes, we have been looking into github rather aggressively. I would
expect something like that to happen.


JD

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

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


>> Ah, good news, glad I was misinformed. I'm curious, what
>> mechanism does it use for trusted?
...
> PHP's "safe mode"
> http://www.php.net/manual/en/features.safe-mode.php
>
> ... which, now I realize, has been deprecated ...

Yeah, safe mode is tough no matter what the language.

Big pink warning from that page:

"This feature has been DEPRECATED as of PHP 5.3.0.
Relying on this feature is highly discouraged."

Since this seems to effectively kill pl/php (leaving
just pl/phpU), you might want to look into the hoops
we've jumped through lately to make pl/perl safe
(or rather, safer :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201007131614
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkw8yVUACgkQvJuQZxSWSsjChwCgtaLaw/f2lB3TxysaFbm1dP5k
Bq0An2FMcSLiFk3D82n75o0ZxfN/8GGv
=yNCa
-----END PGP SIGNATURE-----