Thread: pl/php for windows
Hi, Is it possible that we can install pl/php on windows? where can i get the installer of it? thanks a lot. -- Roche Tumlad Magsayo rtmsoft@yahoo.com +639066642747
roche magsayo wrote: > Hi, > > Is it possible that we can install pl/php on windows? where can i get > the installer of it? thanks a lot. > Which do you want, Perl or PHP? Active State <http://www.activestate.com/activeperl/> has a free Perl package that has been the reference for Perl on Windows. I had been using that for several years. But Google's Summer of Code produced the Camelbox <http://code.google.com/p/camelbox/> last year, which also is quite good. I now use the latter at work, and the best feature is that it uses the core CPAN server and mirrors instead of Active State's less than complete mirror. An alternate method is to install Cygwin <http://www.cygwin.com/> from Red Hat. That not only gives you Perl, but a complete POSIX style workspace, including the Bourne Again Shell (BASH), GCC and the full Unix style utility kit. But if you do go with this, heed their warning about not sending email to the developers. Some of those folks have very sensitive egos and will react violently to the most trivial comments. I have heard that there are command line interpreters for PHP available, but have never used one. The normal way to get it is install an Apache server with the PHP module. You may have to recompile PHP if the default options aren't correct for you. I always have to do that on Linux because a few years ago we discovered Postgres is much better than the MySQL for serious commercial use. Bob McConnell N2SPP
On Wed, 2009-02-18 at 19:38 -0500, Bob McConnell wrote: > roche magsayo wrote: > > Hi, > > > > Is it possible that we can install pl/php on windows? where can i get > > the installer of it? thanks a lot. > > > > Which do you want, Perl or PHP? I suspect he wanted this: http://www.commandprompt.com/community/plphp/ Which is PL/PHP, allowing you to write your stored procedures in PHP, to go with PL/PgSQL, PL/Perl, PL/Ruby and so forth. I haven't used Windows since sometime last millennium though, so I can't offer any help regarding getting it working in such an environment :-( Cheers, Andrew. ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Bruce Schneier can log into any computer just by staring down the prompt. ------------------------------------------------------------------------
Andrew McMillan wrote: > I suspect he wanted this: > > http://www.commandprompt.com/community/plphp/ > > Which is PL/PHP, allowing you to write your stored procedures in PHP, to > go with PL/PgSQL, PL/Perl, PL/Ruby and so forth. And that would explain my confusion. Such a question would make more sense on the Postgres mailing list. And while I use Postgres both at work and at home, we have a company policy forbidding stored procedures, so I am not familiar with those tool sets. Thanks, Bob McConnell N2SPP
On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell <rmcconne@lightlink.com> wrote: > (...) we have a company policy forbidding stored procedures (...) Why would that be? Just curious...
On Thu, 2009-02-19 at 01:34 -0500, Rodrigo E. De León Plicet wrote:
> On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell <rmcconne@lightlink.com> wrote:
> > (...) we have a company policy forbidding stored procedures (...)
>
> Why would that be?
>
> Just curious...
I can't speak for Bob, and they probably have different reasons, but
personally I almost always only write stored procedures in SQL or
PL/PgSQL, and I think very hard about it before deciding to do so, and
try and be careful to design to a minimal functionality that can then be
used in normal SQL.
There can be memory effects from loading a large interpreter into a
PostgreSQL client, which can cause pain if you have many connections,
but mostly I don't trust the software versions to become wildly out of
sync and multiply the installation & maintenance complexity.
PostgreSQL also can have some problems planning queries containing
functions.
... that said, I *have* written a set of functions in PL/PgSQL for
parsing iCalendar RRULE + DTSTART into a SETOF TIMESTAMP. Just purely
for giggles, of course :-)
Cheers,
Andrew.
PS. In a past life I was responsible for maintaining an application
written entirely in Oracle's PL/SQL. I don't ever want to repeat that,
so that probably imposes a bias of sorts too!
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You never hesitate to tackle the most difficult problems.
------------------------------------------------------------------------
Rodrigo E. De León Plicet wrote: > On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell <rmcconne@lightlink.com> wrote: >> (...) we have a company policy forbidding stored procedures (...) > > Why would that be? > > Just curious... > There are a couple of reasons. First, even when written in SQL, stored procedures are not all that portable. In addition to Postgres, our systems use Oracle, Sybase ASA and Microsoft SQL Server. That's what happens when you buy and absorb other companies. Fortunately, the primary application I work with only supports Postgres. It is happily processing tens of thousands of transactions each day. Second, some of those servers are very slow when running stored procedures and we don't have time to spend optimizing procedures for each server. It's even more difficult for the Oracle servers which we don't manage. We will only support that option when the client already has a site license and full time DBA. Now, there are a few instances where a case has been made and accepted to use some specific stored procedures. But that choice is always made on a case by case basis, with significant evaluation backing up the decision. More requests have been turned down than accepted. Bob McConnell N2SPP
Andrew McMillan schrieb: > On Thu, 2009-02-19 at 01:34 -0500, Rodrigo E. De León Plicet wrote: >> On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell <rmcconne@lightlink.com> wrote: >>> (...) we have a company policy forbidding stored procedures (...) >> Why would that be? >> >> Just curious... > > I can't speak for Bob, and they probably have different reasons, but > personally I almost always only write stored procedures in SQL or > PL/PgSQL, and I think very hard about it before deciding to do so, and > try and be careful to design to a minimal functionality that can then be > used in normal SQL. > > There can be memory effects from loading a large interpreter into a > PostgreSQL client, which can cause pain if you have many connections, > but mostly I don't trust the software versions to become wildly out of > sync and multiply the installation & maintenance complexity. > > PostgreSQL also can have some problems planning queries containing > functions. Hi Andrew, woooh .... sounds like giving the advice to reduce the usage of user defined functions to a minimum. But in my opinion it should be a good idea to move functionality to the database in case you work with a Language like PHP. As I recognized it is a good idea to do so 'cause the database is often faster than PHP. I am speaking of PL/pgsql and SQL udf's. Did I misunterstand you? Are there other experiences? In which cases is the planner forced to have problems with statements containing udf's? Cheers Andy > > ... that said, I *have* written a set of functions in PL/PgSQL for > parsing iCalendar RRULE + DTSTART into a SETOF TIMESTAMP. Just purely > for giggles, of course :-) > > Cheers, > Andrew. > > PS. In a past life I was responsible for maintaining an application > written entirely in Oracle's PL/SQL. I don't ever want to repeat that, > so that probably imposes a bias of sorts too! > > ------------------------------------------------------------------------ > andrew (AT) morphoss (DOT) com +64(272)DEBIAN > You never hesitate to tackle the most difficult problems. > ------------------------------------------------------------------------ > > >
On Sat, 2009-03-07 at 18:51 +0100, Andreas Wenk wrote:
>
> Hi Andrew,
>
> woooh .... sounds like giving the advice to reduce the usage of user
> defined functions to a minimum. But in my opinion it should be a good
> idea to move functionality to the database in case you work with a
> Language like PHP. As I recognized it is a good idea to do so 'cause the
> database is often faster than PHP.
>
> I am speaking of PL/pgsql and SQL udf's.
>
> Did I misunterstand you? Are there other experiences? In which cases is
> the planner forced to have problems with statements containing udf's?
From what I have seen, sometimes the planner can have no idea about the
costs of a function. This is essentially an unsolvable problem -
consider the case where for certain values of input a complex select
may/may not be performed. Consequently the planner doesn't try very
hard, and assigns a default performance cost for the function call which
may be wildly wrong.
But there can definitely be performance improvements from functions in
the database, where communication may be faster. I'm not blindly in
favour of either approach, though I have had horrible experiences having
to maintain an Oracle application where *everything* was in database
functions, so serving most pages came down to something like:
SELECT some_function(input1,input2) FROM dual;
There was a lot of developer overhead in writing in that way, because
Oracle developers are (very) expensive, development is generally slower
than in PHP or Perl or modern scripting languages. Also, in that case,
there was little value in the meagre performance increases.
My experience strongly suggests that PHP programmers are many orders of
magnitude easier to find than PL/PgSQL programmers, so I try not to
write much more in PL/PgSQL than is necessary for performance (or
simplicity) reasons, and I try and keep my functions small (not always
successfully :-).
That said, I think more people *should* understand PL/PgSQL, and I have
a very successful 1-2 hour talk I can give at the drop of a hat which
introduces people to many interesting features of PL/PgSQL by going over
the solution to a particular problem which only an idiot would want to
solve in the language. And it turns out that my code to do that in
PL/PgSQL is around 400 lines, compared with around 700 lines for some
equivalent code I have written in PHP.
So by no means am I saying "don't use in-database functions". I'm
saying think carefully about it, considering:
* development costs
* maintenance costs
* performance gains / losses
* additional per connection memory for the interpreter
That last one doesn't apply so much for PL/SQL and probably not
particularly for PL/PgSQL which has a low memory footprint, as far as I
can see.
But yeah, I guess I am advocating that development and maintenance costs
are significantly greater for in-database functions, so don't use them
everywhere. They can also have unanticipated effects on performance, so
even when you do decide to use them make sure you check your assumptions
about performance improvement before spending too much time and effort
on it.
Cheers,
Andrew McMillan.
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Executive ability is prominent in your make-up.
------------------------------------------------------------------------
Andrew McMillan schrieb: > On Sat, 2009-03-07 at 18:51 +0100, Andreas Wenk wrote: >> Hi Andrew, >> >> woooh .... sounds like giving the advice to reduce the usage of user >> defined functions to a minimum. But in my opinion it should be a good >> idea to move functionality to the database in case you work with a >> Language like PHP. As I recognized it is a good idea to do so 'cause the >> database is often faster than PHP. >> >> I am speaking of PL/pgsql and SQL udf's. >> >> Did I misunterstand you? Are there other experiences? In which cases is >> the planner forced to have problems with statements containing udf's? > >From what I have seen, sometimes the planner can have no idea about the > costs of a function. This is essentially an unsolvable problem - > consider the case where for certain values of input a complex select > may/may not be performed. Consequently the planner doesn't try very > hard, and assigns a default performance cost for the function call which > may be wildly wrong. > > But there can definitely be performance improvements from functions in > the database, where communication may be faster. I'm not blindly in > favour of either approach, though I have had horrible experiences having > to maintain an Oracle application where *everything* was in database > functions, so serving most pages came down to something like: > > SELECT some_function(input1,input2) FROM dual; > > There was a lot of developer overhead in writing in that way, because > Oracle developers are (very) expensive, development is generally slower > than in PHP or Perl or modern scripting languages. Also, in that case, > there was little value in the meagre performance increases. > > My experience strongly suggests that PHP programmers are many orders of > magnitude easier to find than PL/PgSQL programmers, so I try not to > write much more in PL/PgSQL than is necessary for performance (or > simplicity) reasons, and I try and keep my functions small (not always > successfully :-). > > That said, I think more people *should* understand PL/PgSQL, and I have > a very successful 1-2 hour talk I can give at the drop of a hat which > introduces people to many interesting features of PL/PgSQL by going over > the solution to a particular problem which only an idiot would want to > solve in the language. And it turns out that my code to do that in > PL/PgSQL is around 400 lines, compared with around 700 lines for some > equivalent code I have written in PHP. > > So by no means am I saying "don't use in-database functions". I'm > saying think carefully about it, considering: > > * development costs > * maintenance costs > * performance gains / losses > * additional per connection memory for the interpreter > > That last one doesn't apply so much for PL/SQL and probably not > particularly for PL/PgSQL which has a low memory footprint, as far as I > can see. > > But yeah, I guess I am advocating that development and maintenance costs > are significantly greater for in-database functions, so don't use them > everywhere. They can also have unanticipated effects on performance, so > even when you do decide to use them make sure you check your assumptions > about performance improvement before spending too much time and effort > on it. > > Cheers, > Andrew McMillan. > > ------------------------------------------------------------------------ > andrew (AT) morphoss (DOT) com +64(272)DEBIAN > Executive ability is prominent in your make-up. > ------------------------------------------------------------------------ Hey Andrew, thanks a lot for sharing your experiences. Seems that we have the same point of view. Means one has to compare allways the performance improvement between writing some functionality in the database or in the code like PHP. And another point is having the ability with PL/pgSQL to develop faster - just think about the lousy date calculating implementation in PHP compared to the great date functions in posgresql (and other db's). It turns out, that having this in mind will produce the best results. Cheers Andy