Обсуждение: 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:
--
Shoaib Mir
http://shoaibmir.wordpress.com/
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
--
Shoaib Mir
http://shoaibmir.wordpress.com/
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.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
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-----