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
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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
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
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
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
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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.
------------------------------------------------------------ ------------
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell
> (...) we have a company policy forbidding stored procedures (...)
Why would that be?
Just curious...
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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
> > (...) we have a company policy forbidding stored procedures (...)
>=20
> Why would that be?
>=20
> 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.
------------------------------------------------------------ ------------
--=20
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
Rodrigo E. De León Plicet wrote:
> On Wed, Feb 18, 2009 at 10:04 PM, Bob McConnell
>> (...) we have a company policy forbidding stored procedures (...)
>=20
> Why would that be?
>=20
> Just curious...
>=20
There are a couple of reasons. First, even when written in SQL, stored=20
procedures are not all that portable. In addition to Postgres, our=20
systems use Oracle, Sybase ASA and Microsoft SQL Server. That's what=20
happens when you buy and absorb other companies. Fortunately, the=20
primary application I work with only supports Postgres. It is happily=20
processing tens of thousands of transactions each day.
Second, some of those servers are very slow when running stored=20
procedures and we don't have time to spend optimizing procedures for=20
each server. It's even more difficult for the Oracle servers which we=20
don't manage. We will only support that option when the client already=20
has a site license and full time DBA.
Now, there are a few instances where a case has been made and accepted=20
to use some specific stored procedures. But that choice is always made=20
on a case by case basis, with significant evaluation backing up the=20
decision. More requests have been turned down than accepted.
Bob McConnell
N2SPP
--=20
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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
>>> (...) we have a company policy forbidding stored procedures (...)
>> Why would that be?
>>
>> Just curious...
>=20
> 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 b=
e
> used in normal SQL.
>=20
> 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.
>=20
> PostgreSQL also can have some problems planning queries containing
> functions.
Hi Andrew,
woooh .... sounds like giving the advice to reduce the usage of user=20
defined functions to a minimum. But in my opinion it should be a good=20
idea to move functionality to the database in case you work with a=20
Language like PHP. As I recognized it is a good idea to do so 'cause the=20
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=20
the planner forced to have problems with statements containing udf's?
Cheers
Andy
>=20
> ... 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 :-)
>=20
> Cheers,
> Andrew.
>=20
> 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!
>=20
> ------------------------------------------------------------ -----------=
-
> andrew (AT) morphoss (DOT) com +64(272)DEBIA=
N
> You never hesitate to tackle the most difficult problems.
> ------------------------------------------------------------ -----------=
-
>=20
>=20
>=20
--=20
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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.
------------------------------------------------------------ ------------
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php
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
--
Sent via pgsql-php mailing list (pgsql-php@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-php