Thread: php + postgresql

First, thanks to everyone who responded to my newbie questions
yesterday, all clear now.

I spent most of today struggling with apparently inconsistent behaviour
while running SELECT statements on PG 8.1.9 using PHP 5.1.6 (these are
both as supplied with CentOS 5.1, a fairly conservative distro).

It seems that some of PHP's PG functions have changed recently, are
there any known issues with them?

1.
I ended up using pg_prepare() and pg_execute() as pg_query() alone just
didn't seem to work. But SELECT statements seemed to be cached or
persistent in some way, such that they "lived" beyond the life of the
PHP script. Is there something I need to know about persistent behaviour
in PG that doesn't exist in MySQL?


2.
Another problem was that no matter how many times I checked and
re-checked code, or which pg_fetch_* function I used, copying an array
member and trying to use it later just would not work, eg

while ($row = pg_fetch_array($query)) {
   $content = $row[0]
}

echo $content;

$content was always 'undeclared'.

3.
Some examples I found used PHP's pg_num_rows() function to count the
rows in a result, then iterated through them with a "for" loop ... is
this required behaviour (PHP docs don't appear to discuss this)?

4.
Another weird one was that this statement always failed:

$name = "file.php";
SELECT fld_content FROM tbl_page WHERE fld_name='$name'

while this one always worked:

SELECT fld_content FROM tbl_page WHERE fld_pid=1

in a three column table:

fld_pid serial PRIMARY KEY,
fld_name varchar(100) NOT NULL,
fld_content text NOT NULL

while everything worked fine from the psql console.


... but this post is getting too unwieldy. I am reading documentation
but am also under some pressure to get basic things up and running. Any
pointers to good documentation covering PHP + PG, or any well known gotchas?

PS If people want to throw MySQL->PostgreSQL gotchas at me I'm happy to
collate and write up.

Thanks again
Mick

admin wrote:
> First, thanks to everyone who responded to my newbie questions
> yesterday, all clear now.
>
> I spent most of today struggling with apparently inconsistent behaviour
> while running SELECT statements on PG 8.1.9 using PHP 5.1.6 (these are
> both as supplied with CentOS 5.1, a fairly conservative distro).
>
> It seems that some of PHP's PG functions have changed recently, are
> there any known issues with them?
>
> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or
> persistent in some way, such that they "lived" beyond the life of the
> PHP script. Is there something I need to know about persistent behaviour
> in PG that doesn't exist in MySQL?

It sounds like you must be using a connection pooler, so your scripts
are acquiring connections that've already been used and had statements
prepared for them. If you try to prepare a new statement with the same
name it'll fail.

I understand that this is a common issue with simple connection poolers,
but as I don't deal with them myself I don't have any suggestions for
you. Others here may, and I'm sure Google can help out too.

> 3.
> Some examples I found used PHP's pg_num_rows() function to count the
> rows in a result, then iterated through them with a "for" loop ... is
> this required behaviour (PHP docs don't appear to discuss this)?

Required by what? I'm not sure I really understand your question.

Do you mean "does PostgreSQL always return a row count that can then be
accessed with pg_num_rows()" ?

Or:

"Must I iterate through a resultset with a loop over pg_num_rows()
rather than using some other method to iterate through the resultset" ?

> 4.
> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'

"failed" how? What did you expect to happen? What happened instead? What
was the exact error message?

You always need to ask yourself those questions when reporting any sort
of problem. Otherwise, the people reading your question will just have
to ask them, so you'll get slower and less useful responses (and fewer
of them, as many people will just ignore poorly written questions).

--
Craig Ringer

On 24/07/2008 10:41, admin wrote:

> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or
> persistent in some way, such that they "lived" beyond the life of the
> PHP script. Is there something I need to know about persistent behaviour
> in PG that doesn't exist in MySQL?

That's not something I've ever encountered, and I've done a good bit of
PHP+PG at this stage. Can you show us an example? Also, how are you
connecting? - are you simply doing pg_connect(....) to connect directly,
or is there anything else in the middle - maybe a connection pooler of
some kind?


> Another problem was that no matter how many times I checked and
> re-checked code, or which pg_fetch_* function I used, copying an array
> member and trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>   $content = $row[0]
> }
>
> echo $content;
>
> $content was always 'undeclared'.

Again, this ought to be fine as you've shown it....can you show us the
SELECT statement and other information?


> Some examples I found used PHP's pg_num_rows() function to count the
> rows in a result, then iterated through them with a "for" loop ... is
> this required behaviour (PHP docs don't appear to discuss this)?

No real need - I generally use the idiom you have above -

   $rs = pg_query($sql_string);
   while ($row = pg_fetch_assoc($rs)
   {
     $value = $row['col1'];
     // etc....
   }


> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'

That's because you need to use double-inverted-commas for string
interpolation:

   ...WHERE fld_name = "$name"


Ray.

------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

admin wrote:
> First, thanks to everyone who responded to my newbie questions
> yesterday, all clear now.
>
> I spent most of today struggling with apparently inconsistent behaviour
> while running SELECT statements on PG 8.1.9 using PHP 5.1.6 (these are
> both as supplied with CentOS 5.1, a fairly conservative distro).
>
> It seems that some of PHP's PG functions have changed recently, are
> there any known issues with them?

PHP's functions change on a regular basis I'm afraid. There's a
changelog to track the detail, but the docs give details of larger
changes. You might find it simplest to refer to the docs that come with
your distro.

> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or
> persistent in some way, such that they "lived" beyond the life of the
> PHP script. Is there something I need to know about persistent behaviour
> in PG that doesn't exist in MySQL?

You're probably using persistent connections. Don't - they're not much
use with a standard Apache+PHP installation. Prepared queries last for
the length of a session (connection).

> 2.
> Another problem was that no matter how many times I checked and
> re-checked code, or which pg_fetch_* function I used, copying an array
> member and trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>   $content = $row[0]
> }
>
> echo $content;
>
> $content was always 'undeclared'.

Nothing leaping out at me, but don't refer to columns by index, refer to
them by name.

> 3.
> Some examples I found used PHP's pg_num_rows() function to count the
> rows in a result, then iterated through them with a "for" loop ... is
> this required behaviour (PHP docs don't appear to discuss this)?

Not required. The while($row=) works if you want all rows. Of course if
you just want a page of 20 or so then you might want a for loop.

> 4.
> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'
>
> while this one always worked:
>
> SELECT fld_content FROM tbl_page WHERE fld_pid=1

1. Don't interpolate variables directly into SQL. Use the parameterised
query functions.
2. Check the error message to see why there's a problem.

> ... but this post is getting too unwieldy. I am reading documentation
> but am also under some pressure to get basic things up and running. Any
> pointers to good documentation covering PHP + PG, or any well known
> gotchas?

None (other than the fact that persistent connections don't work how a
newbie might want).

> PS If people want to throw MySQL->PostgreSQL gotchas at me I'm happy to
> collate and write up.

Traditionally MySQL is very "relaxed" about data validity. PostgreSQL
isn't and dates of 00-00-0000 aren't allowed. There are pages of "mysql
gotchas" and "postgresql gotchas" too - google for them.

--
   Richard Huxton
   Archonet Ltd

Hi Mick,

> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone
> just didn't seem to work. But SELECT statements seemed to be cached
> or persistent in some way, such that they "lived" beyond the life of
> the PHP script. Is there something I need to know about persistent
> behaviour in PG that doesn't exist in MySQL?

Do you have an example? and what makes you say they are persisting?

> 2.
> Another problem was that no matter how many times I checked and re-
> checked code, or which pg_fetch_* function I used, copying an array
> member and trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>  $content = $row[0]
> }
>
> echo $content;
>
> $content was always 'undeclared'.

are you sure pg_fetch_array($query) is returning any rows? (try echo
$row[0]; within the while loop)

> 3.
> Some examples I found used PHP's pg_num_rows() function to count the
> rows in a result, then iterated through them with a "for" loop ...
> is this required behaviour (PHP docs don't appear to discuss this)?

I often do something along the lines of this:

if($stat = pg_exec($dbh, $sql))
     {
      if($rows = pg_numrows($stat))
          {
            for($i=0; $i < $rows; $i++)
                  {
                   $data = pg_fetch_array($stat, $i);

                   # do something with $data
                  }
          }
      else{echo "no rows returned";}
    }
  else{echo "query failed";}

> 4.
> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'

is $name being interpolated correctly when you use it.... maybe use:

$sql = "SELECT fld_content FROM tbl_page WHERE fld_name='".$name."'";

(or use a prepared statement)

> while this one always worked:
>
> SELECT fld_content FROM tbl_page WHERE fld_pid=1
>
> in a three column table:
>
> fld_pid serial PRIMARY KEY,
> fld_name varchar(100) NOT NULL,
> fld_content text NOT NULL
>
> while everything worked fine from the psql console.
>
>
> ... but this post is getting too unwieldy. I am reading
> documentation but am also under some pressure to get basic things up
> and running. Any pointers to good documentation covering PHP + PG,
> or any well known gotchas?
>
> PS If people want to throw MySQL->PostgreSQL gotchas at me I'm happy
> to collate and write up.
>
> Thanks again
> Mick
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

On 24/07/2008 11:13, Raymond O'Donnell wrote:
>   $rs = pg_query($sql_string);
>   while ($row = pg_fetch_assoc($rs)

Whoops! -

   while ($row = pg_fetch_assoc($rs))
   ....

Ray.

------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
------------------------------------------------------------------

On Thursday 24. July 2008, admin wrote:

>It seems that some of PHP's PG functions have changed recently, are
>there any known issues with them?

I've been using PHP with PostgreSQL for 5 years, and haven't noticed any
substantial changes.

>while ($row = pg_fetch_array($query)) {
>   $content = $row[0]
>}
>
>echo $content;
>
>$content was always 'undeclared'.

You have to use an intermediate variable like a handle. Try this:

$handle = pg_query("SELECT whatever FROM foo");
while ($row = pg_fetch_array($handle) {
    $content = $row[0];
}

> Any pointers to good documentation covering PHP + PG, or any well
> known gotchas?

You can download my pg+php genealogy app "exodus" from here:

http://solumslekt.org/forays/exodus.tgz

The code is certainly not stellar, but it works for me. Note that the
code is intended for running in a private environment, and there are no
security features whatsoever.
--
Leif Biberg Kristensen | Registered Linux User #338009
Me And My Database: http://solumslekt.org/blog/
My Jazz Jukebox: http://www.last.fm/user/leifbk/

On Thu, 24 Jul 2008 19:11:36 +0930
admin <mick@mjhall.org> wrote:

> 2.
> Another problem was that no matter how many times I checked and
> re-checked code, or which pg_fetch_* function I used, copying an
> array member and trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>    $content = $row[0]
> }
>
> echo $content;
>
> $content was always 'undeclared'.

Did the result contain at least 1 row?
Also prefer column names. If you change the schema, order etc...
you'll have less chances to break code.

What do you mean by 'undeclared'?

if(!isset($content)) ?

or just

echo $content doesn't return output?

what about
$content .= $row[0]." # ";
for quick debugging?

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

On Thu, 24 Jul 2008 12:30:22 +0200
"Leif B. Kristensen" <leif@solumslekt.org> wrote:

> On Thursday 24. July 2008, admin wrote:

> >while ($row = pg_fetch_array($query)) {
> >   $content = $row[0]
> >}
> >
> >echo $content;
> >
> >$content was always 'undeclared'.
>
> You have to use an intermediate variable like a handle. Try this:
>
> $handle = pg_query("SELECT whatever FROM foo");
> while ($row = pg_fetch_array($handle) {
>     $content = $row[0];
> }

ivan@dawn:~$ php -a
Interactive mode enabled

<?php
echo pg_fetch_array($pippo);

Warning: pg_fetch_array() expects parameter 1 to be resource, null
given in /home/ivan/- on line 2

Call Stack:
   18.3923    1079256   1. {main}() /home/ivan/-:0
   18.3924    1079528   2. pg_fetch_array() /home/ivan/-:2

It can't be the problem. BTW even passing a string will end up in
the same error.

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

Thanks again for replies.
I know those questions were pretty vague.
I need to set up some methodical test scripts that replicate my
problems, so that it is clear what is going on.

There does seem to be some evidence of problems historically with PHP
and persistent connections in PostgreSQL, on the PHP forums. The advice
is typically to avoid them.

Mick

On Thu, Jul 24, 2008 at 6:33 AM, admin <mick@mjhall.org> wrote:
> Thanks again for replies.
> I know those questions were pretty vague.
> I need to set up some methodical test scripts that replicate my problems, so
> that it is clear what is going on.
>
> There does seem to be some evidence of problems historically with PHP and
> persistent connections in PostgreSQL, on the PHP forums. The advice is
> typically to avoid them.

php and persistant connections are a foot gun for any database really.
 There are very strict provisioning rules you have to follow to use
them correctly, and they are often NOT the best answer for a given
problem.  Until they are. :)

Mick,

As I haven't seen anyone else say it, I just wanted to throw this in.

I'm not a PHP programmer, so I'm not very sure of PHP's scoping rules,
but this looks to me like a variable scoping problem. If the first
time you've used $content is inside of the while(), it's probably
going out of scope before your echo. Try this:


# Initialize $content before going into the loop.
# This declares it outside the scope of the while()

$content=''';

# Now do your loop

while ($row = pg_fetch_array($query)) {
$content = $row[0]
}

echo $content;



Your loop is a little weird, too. You're not accumulating anything,
you're just saving the previous value. When you exit the loop,
$content will only contain the value from the final row. If that's
your intent, you may save some time by reverse-ordering your query and
using "limit 1". That way you can remove the loop altogether and save
lots of processing time.


--
David Spadea



On Thu, Jul 24, 2008 at 5:41 AM, admin <mick@mjhall.org> wrote:
> First, thanks to everyone who responded to my newbie questions yesterday,
> all clear now.
>
> I spent most of today struggling with apparently inconsistent behaviour
> while running SELECT statements on PG 8.1.9 using PHP 5.1.6 (these are both
> as supplied with CentOS 5.1, a fairly conservative distro).
>
> It seems that some of PHP's PG functions have changed recently, are there
> any known issues with them?
>
> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or persistent
> in some way, such that they "lived" beyond the life of the PHP script. Is
> there something I need to know about persistent behaviour in PG that doesn't
> exist in MySQL?
>
>
> 2.
> Another problem was that no matter how many times I checked and re-checked
> code, or which pg_fetch_* function I used, copying an array member and
> trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>  $content = $row[0]
> }
>
> echo $content;
>
> $content was always 'undeclared'.
>
> 3.
> Some examples I found used PHP's pg_num_rows() function to count the rows in
> a result, then iterated through them with a "for" loop ... is this required
> behaviour (PHP docs don't appear to discuss this)?
>
> 4.
> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'
>
> while this one always worked:
>
> SELECT fld_content FROM tbl_page WHERE fld_pid=1
>
> in a three column table:
>
> fld_pid serial PRIMARY KEY,
> fld_name varchar(100) NOT NULL,
> fld_content text NOT NULL
>
> while everything worked fine from the psql console.
>
>
> ... but this post is getting too unwieldy. I am reading documentation but am
> also under some pressure to get basic things up and running. Any pointers to
> good documentation covering PHP + PG, or any well known gotchas?
>
> PS If people want to throw MySQL->PostgreSQL gotchas at me I'm happy to
> collate and write up.
>
> Thanks again
> Mick
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

On Thu, 24 Jul 2008 11:13:52 -0400
"David Spadea" <david.spadea@gmail.com> wrote:

> Mick,
>
> As I haven't seen anyone else say it, I just wanted to throw this
> in.
>
> I'm not a PHP programmer, so I'm not very sure of PHP's scoping
> rules, but this looks to me like a variable scoping problem. If
> the first time you've used $content is inside of the while(), it's
> probably going out of scope before your echo. Try this:

ivan@dawn:~$ php -a
Interactive mode enabled

<?php
if(true) {
        $content="it exixts";
}
print $content;
it exixts

The code and PHP scoping are not nice but it should prove that
scoping is not the problem ;)

> # Initialize $content before going into the loop.
> # This declares it outside the scope of the while()
>
> $content=''';

mistype

> # Now do your loop
>
> while ($row = pg_fetch_array($query)) {
> $content = $row[0]
> }
>
> echo $content;
>
>
>
> Your loop is a little weird, too. You're not accumulating anything,
> you're just saving the previous value. When you exit the loop,
> $content will only contain the value from the final row. If that's

for debugging I suggested:
$content .= $row[0]." # ";
So he could see if any row even if all $row[0] contained '' or null.


--
Ivan Sergio Borgonovo
http://www.webthatworks.it

On Thursday 24 July 2008 12:41, admin wrote:
> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or
> persistent in some way, such that they "lived" beyond the life of the
> PHP script. Is there something I need to know about persistent behaviour
> in PG that doesn't exist in MySQL?

Not sure what causes this with your server but I always use something like
this, ie first connect then do your stuff and then close the connection:

require("dbconnect.inc"); // holds the $conn which is pg_connect("with
passes")

if (!$conn)
  {exit("Database connection failed. Please try again." . $conn);}

$sql ="SELECT ...";

$product=pg_exec($conn,$sql);
if (!$product)
  {exit("Database connection failed. Please try again.");}

while ($row = pg_fetch_row($product))
{
echo"

$row[1]

";
}

pg_close($conn);

BR,
--
Aarni

Burglars usually come in through your windows.

> There does seem to be some evidence of problems historically with PHP
> and persistent connections in PostgreSQL, on the PHP forums. The advice
> is typically to avoid them.

You'll find the same advice for mysql + persistent connections or any
other db + persistent connections. It's not a php+postgres thing.

--
Postgresql & php tutorials
http://www.designmagick.com/

> 2.
> Another problem was that no matter how many times I checked and
> re-checked code, or which pg_fetch_* function I used, copying an array
> member and trying to use it later just would not work, eg
>
> while ($row = pg_fetch_array($query)) {
>   $content = $row[0]
> }
>
> echo $content;


pg_fetch_array expects a result from a query, not an actual sql query.

You need something like this:

$query = "select id, name from tablename";
$result = pg_query($query);
while ($row = pg_fetch_array($result)) {
  $content = $row[0];
}


> 3.
> Some examples I found used PHP's pg_num_rows() function to count the
> rows in a result, then iterated through them with a "for" loop ... is
> this required behaviour (PHP docs don't appear to discuss this)?

You used to have to do this but you don't any more.

The old style was something like:

<?php
....

$result = pg_query($query);
$rows = pg_num_rows($result);

for ($row_num = 0; $row_num < $rows; $row_num++) {
  $db_row = pg_fetch_array($result, $row_num);
}

The new style works like:

<?php
....

$result = pg_query($query);
while ($row = pg_fetch_array($result)) {
  $db_row = pg_fetch_array($result);
}


This was changed a lot time ago (according to the php manual - 4.1.0).

> 4.
> Another weird one was that this statement always failed:
>
> $name = "file.php";
> SELECT fld_content FROM tbl_page WHERE fld_name='$name'

Escape your data:

$name = 'blah';
$query = "SELECT fld_content FROM tbl_page WHERE fld_name='" .
pg_escape_string($name) . "'";

<shameless plug>
I have some intro guides here you might want to check out:

http://www.designmagick.com/category/2/
</shameless plug>

--
Postgresql & php tutorials
http://www.designmagick.com/

> You need something like this:
>
> $query = "select id, name from tablename";
> $result = pg_query($query);
> while ($row = pg_fetch_array($result)) {
>   $content = $row[0];
> }

That's actually what I was using.
The scoping wasn't the issue either.

Today I switched back to pg_connect() from pg_pconnect(), made some
changes to my overall architecture and re-wrote my database stuff. Then
re-booted.

Not sure what fixed it but all working now. I'm only working on a draft
"skeleton" right now so am free to fiddle.

Keep finding cool features in PostgreSQL, I think I'm sold!

Thanks
Mick

In response to Chris <dmagick@gmail.com>:
>
> > There does seem to be some evidence of problems historically with PHP
> > and persistent connections in PostgreSQL, on the PHP forums. The advice
> > is typically to avoid them.
>
> You'll find the same advice for mysql + persistent connections or any
> other db + persistent connections. It's not a php+postgres thing.

They're manageable if you know all the ins and outs.  The big advantage
is speed, as they avoid the cost of establishing the initial TCP
connection and logging in.  In my experiments, this cut the run time
for the average script in half.

But you have to deal with managing an overwhelming # of perpetually
open connections, which takes a lot of resources on both the server and
the client side, in addition to problems like connection settings persisting
from one script to the next.

My opinion is avoid them unless you have a demonstrated need for the
speed increase.  In that case, make sure you have the time to understand
and code for all the potential issues.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

Hi,

admin wrote:
> Thanks again for replies.
> I know those questions were pretty vague.
> I need to set up some methodical test scripts that replicate my
> problems, so that it is clear what is going on.
>
> There does seem to be some evidence of problems historically with PHP
> and persistent connections in PostgreSQL, on the PHP forums. The advice
> is typically to avoid them.

usually it goes so far to avoid PHP alltogether ;)
Is there any special reason to use PHP? There are
a couple other scripting languages useable for the
web which do all have better abstration available.
(afaic even PHP does have some more abstration to
  just using pg* functions)

Tino.

Aarni Ruuhimäki wrote:
...
> Not sure what causes this with your server but I always use something like
> this, ie first connect then do your stuff and then close the connection:
>
> require("dbconnect.inc"); // holds the $conn which is pg_connect("with
> passes")

I would avoid that in favour of using $HOME/.pgpass

http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html

HTH
Tino

On Friday 25 July 2008 15:33, you wrote:
>
> I would avoid that in favour of using $HOME/.pgpass
>
> http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
>
> HTH
> Tino

Hi,

Quite right you are. Or something like this?

require("/eg/unknown_path/deep_somewhere_else/dbconnect_app_name.php");

BR,

Aarni
--
Burglars usually come in through your windows.

> Is there any special reason to use PHP? There are
> a couple other scripting languages useable for the
> web which do all have better abstration available.
> (afaic even PHP does have some more abstration to
>  just using pg* functions)

Well, yes, there are alternatives of course and I could write this stuff
in perl or python but it'd take me 10 times as long because my
experience is elsewhere. Learning new stuff is always good, but at the
end of the day I get paid for making stuff work on time and in budget
... mostly :-)

I think that PHP (like PostgreSQL, perhaps?) suffers from a reputation
hangover from years ago. PostgreSQL was supposedly "slow", PHP is
supposedly "undisciplined" and "unprofessional". You sure can still
write spaghetti with PHP5 if you want to, but you can also write decent
code with planning and standards. But good, bad or ugly, it's what I
personally am most productive in.

I have used PHP's PEAR DB abstraction class many times. It doen't really
save much time or effort writing code, and has a performance overhead. I
don't need to allow the possibility of switching to another database and
stuff like that.

Mick

Hi,

admin wrote:
>> Is there any special reason to use PHP? There are
>> a couple other scripting languages useable for the
>> web which do all have better abstration available.
>> (afaic even PHP does have some more abstration to
>>  just using pg* functions)
>
> Well, yes, there are alternatives of course and I could write this stuff
> in perl or python but it'd take me 10 times as long because my
> experience is elsewhere. Learning new stuff is always good, but at the
> end of the day I get paid for making stuff work on time and in budget
> ... mostly :-)
>
> I think that PHP (like PostgreSQL, perhaps?) suffers from a reputation
> hangover from years ago. PostgreSQL was supposedly "slow", PHP is
> supposedly "undisciplined" and "unprofessional". You sure can still

Well no PHP is conceptual undisciplined and confusing. I would
not compare this with Postgresql itself which is very professional
developed with a great vision. PHP is just and always was a hack.

> write spaghetti with PHP5 if you want to, but you can also write decent
> code with planning and standards. But good, bad or ugly, it's what I
> personally am most productive in.
>
> I have used PHP's PEAR DB abstraction class many times. It doen't really
> save much time or effort writing code, and has a performance overhead. I
> don't need to allow the possibility of switching to another database and
> stuff like that.

Sure, you must consider it yourself but having a little abstraction
helps even as kind of inherent documentation when you later need to
touch your code again.

Regards
Tino

On Fri, 2008-07-25 at 17:40 +0200, Tino Wildenhain wrote:
> Hi,
>
> > I think that PHP (like PostgreSQL, perhaps?) suffers from a reputation
> > hangover from years ago. PostgreSQL was supposedly "slow", PHP is
> > supposedly "undisciplined" and "unprofessional". You sure can still
>
> Well no PHP is conceptual undisciplined and confusing. I would
> not compare this with Postgresql itself which is very professional
> developed with a great vision. PHP is just and always was a hack.

I actually think that the analogy is valid. *Most* PHP users don't know
its a hack, those same users are going to be the ones that think
PostgreSQL is slow.

Joshua D. Drake

P.S. To be fair, PHP has gotten much better over the last few releases.

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Obviously he is a newbie out of the woods- couldn't make a connection
and print results something that the rest of us have been doing for
years. It is newbies like him and fan-boys of Ruby/Python/Perl who
give PHP a bad name. But I fail to understand the little animosity
within some PostgreSQL users to PHP- is it the LAMP stack?
Cheers, Bill

On Fri, Jul 25, 2008 at 11:53 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Fri, 2008-07-25 at 17:40 +0200, Tino Wildenhain wrote:
>> Hi,
>>
>> > I think that PHP (like PostgreSQL, perhaps?) suffers from a reputation
>> > hangover from years ago. PostgreSQL was supposedly "slow", PHP is
>> > supposedly "undisciplined" and "unprofessional". You sure can still
>>
>> Well no PHP is conceptual undisciplined and confusing. I would
>> not compare this with Postgresql itself which is very professional
>> developed with a great vision. PHP is just and always was a hack.
>
> I actually think that the analogy is valid. *Most* PHP users don't know
> its a hack, those same users are going to be the ones that think
> PostgreSQL is slow.
>
> Joshua D. Drake
>
> P.S. To be fair, PHP has gotten much better over the last few releases.
>
> --
> The PostgreSQL Company since 1997: http://www.commandprompt.com/
> PostgreSQL Community Conference: http://www.postgresqlconference.org/
> United States PostgreSQL Association: http://www.postgresql.us/
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

I too don't get the animosity.  it's not like you can't write bad code
in perl, java, ruby or python.

The real issue is the quality of the programmer.

On Fri, Jul 25, 2008 at 10:29 AM, Bill Wordsworth
<bill.wordsworth@gmail.com> wrote:
> Obviously he is a newbie out of the woods- couldn't make a connection
> and print results something that the rest of us have been doing for
> years. It is newbies like him and fan-boys of Ruby/Python/Perl who
> give PHP a bad name. But I fail to understand the little animosity
> within some PostgreSQL users to PHP- is it the LAMP stack?
> Cheers, Bill
>
> On Fri, Jul 25, 2008 at 11:53 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> On Fri, 2008-07-25 at 17:40 +0200, Tino Wildenhain wrote:
>>> Hi,
>>>
>>> > I think that PHP (like PostgreSQL, perhaps?) suffers from a reputation
>>> > hangover from years ago. PostgreSQL was supposedly "slow", PHP is
>>> > supposedly "undisciplined" and "unprofessional". You sure can still
>>>
>>> Well no PHP is conceptual undisciplined and confusing. I would
>>> not compare this with Postgresql itself which is very professional
>>> developed with a great vision. PHP is just and always was a hack.
>>
>> I actually think that the analogy is valid. *Most* PHP users don't know
>> its a hack, those same users are going to be the ones that think
>> PostgreSQL is slow.
>>
>> Joshua D. Drake
>>
>> P.S. To be fair, PHP has gotten much better over the last few releases.
>>
>> --
>> The PostgreSQL Company since 1997: http://www.commandprompt.com/
>> PostgreSQL Community Conference: http://www.postgresqlconference.org/
>> United States PostgreSQL Association: http://www.postgresql.us/
>> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
>>
>>
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

On Fri, 2008-07-25 at 12:29 -0400, Bill Wordsworth wrote:
> Obviously he is a newbie out of the woods- couldn't make a connection
> and print results something that the rest of us have been doing for
> years. It is newbies like him and fan-boys of Ruby/Python/Perl who
> give PHP a bad name.

No, it is PHP that gives PHP a bad name. That being said, it depends on
your perception. I personally have zero problem with PHP. It has always
done what I have asked of it. I do however prefer Python.

>  But I fail to understand the little animosity
> within some PostgreSQL users to PHP- is it the LAMP stack?

No. It because PHP is developed wrong. If you talk to "engineers" and
you say to them, "Can you take a look at this code and tell me what you
think?". Any engineer worth their salt is going to tell you that the PHP
code is scary. Whereas the PostgreSQL code is nicely done. (notice I
have not used the word perfect anywhere.)

There are also particulars about the language that are just wrong (as I
understand it). Specifically in consistency, namespace issues and some
others.

Coming from my perspective, I could care less that PHPs code is a
gnarled mess because I am not a C developer. Nor am I what would be
considered a Software Engineer. I am a hack of a developer and a
reasonable DBA/Sysadmin. My job is Consultant.

If I were an Engineer and I work with several, I wouldn't like PHP
either. The majority of known PostgreSQL community people are Engineers.
Thus you get the hating.

Sincerely,

Joshua D. Drake


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Fri Jul 25 01:03 PM, Joshua D. Drake wrote:
> On Fri, 2008-07-25 at 12:29 -0400, Bill Wordsworth wrote:
>> Obviously he is a newbie out of the woods- couldn't make a connection
>> and print results something that the rest of us have been doing for
>> years. It is newbies like him and fan-boys of Ruby/Python/Perl who
>> give PHP a bad name.
>
> No. It because PHP is developed wrong. If you talk to "engineers" and
> you say to them, "Can you take a look at this code and tell me what
> you think?". Any engineer worth their salt is going to tell you that
> the PHP code is scary. Whereas the PostgreSQL code is nicely done.
> (notice I have not used the word perfect anywhere.)

Uhm, let's not start a PHP debate. Traditionally PHP in terms of design
philosophy is more
like mySQL: "whatever works". PostgreSQL is more an enterprise level
database and cares about
the "enterprise" architecture.

"PHP is just and always was a hack."
I'd say "the Web is just and always was a hack", so for the Web: PHP is an
excellent language and in my opinion the best.
I don't like statements like "is developed wrong", there's no right or wrong
just different approaches to specific problems with advantages and
disadvantages.

You don't see people making hats out of heavily engineered machines do you?
That said PHP is improving and does deserve more "enterprise respect" mostly
thanks to support from Zend (http://www.zend.com/en/) and other companies.

I use .NET, java and PHP and with experience you learn to use/speak the
right language for the job. "hack" languages sometimes get the job done
faster.

On Fri, 2008-07-25 at 13:41 -0400, Jonathan Bond-Caron wrote:
> On Fri Jul 25 01:03 PM, Joshua D. Drake wrote:

> I use .NET, java and PHP and with experience you learn to use/speak the
> right language for the job. "hack" languages sometimes get the job done
> faster.

You seemed to have completely missed the point of my post.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Fri, Jul 25, 2008 at 01:41:50PM -0400, Jonathan Bond-Caron wrote:

> Uhm, let's not start a PHP debate.

The post would have been more effective if you'd stopped there ;-)

That said,

> I'd say "the Web is just and always was a hack"

I have to object to this pretty strongly.  What premises do you have
for this argument?  It seems to me that the http and (at least
recently) xhtml specifications have been pretty rigorous.  That rigour
is actually one of the things many people who want to "get 'er done"
complain about.

(Note, however, that I'm firmly in the camp that says you can write
lousy code in any language.)

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

On Jul 25, 2008, at 11:20 AM, Andrew Sullivan wrote:

> On Fri, Jul 25, 2008 at 01:41:50PM -0400, Jonathan Bond-Caron wrote:
>
>> I'd say "the Web is just and always was a hack"
>
> I have to object to this pretty strongly.

He has a point, though.  If you were starting out to build a user
interface framework for building applications to be used by general
users, I really doubt you'd end up with the current situation of
HTTP, HTML, CSS, Javascript.  But that's no matter, really, because
here we are.

Same for PHP.  If you wanted to build a great, elegant, scripting
language for writing web front ends, you almost certainly would not
end up with PHP.  But, here we are.  Coming from a C++ and Java
background, I find PHP to be just nasty in a lot of ways, but it gets
the job done.

Most developers don't make deep informed decisions about PHP vs other
languages.  They use it because everyone else is, there is a huge
ecosystem of support around it, it's easy to get something flopping
around on the table quickly, and they know *for sure* that they can
host it anywhere.  Which, really, are not terrible reasons to pick a
development environment.

Dragging the subject back to PostgreSQL, it's the same thing with
MySQL vs PG.  Very few people do detailed technical analyses of
exactly which DB to use (and, if they do, they use PG :) ).  They use
MySQL because everyone else does, it gets the job done (or at least
appears to), and, most importantly, every $9.95/month hosting plan in
the world includes MySQL because Wordpress requires it.

Andrew Sullivan wrote:
> On Fri, Jul 25, 2008 at 01:41:50PM -0400, Jonathan Bond-Caron wrote:
>
>> Uhm, let's not start a PHP debate.

Well it was just a innocent question since the original poster did
not seem to know the language of choice good enough to solve this
rather basic problem.

> (Note, however, that I'm firmly in the camp that says you can write
> lousy code in any language.)

Sure, but it seems some languages makes it more easy to write lousy
code instead of something elegant. (And be it just because they
are so common that you just have a bay of bad examples to choose from,
add some cargo cult programming and be ready :-)

Ok, back on topic again :-)

T.

On Fri Jul 25 02:20 PM, Andrew Sullivan wrote:
> On Fri, Jul 25, 2008 at 01:41:50PM -0400, Jonathan Bond-Caron wrote:
>
>> Uhm, let's not start a PHP debate.
>
> The post would have been more effective if you'd stopped there ;-)

Agreed :)

> That said,
>
>> I'd say "the Web is just and always was a hack"
>
> I have to object to this pretty strongly.

I should take that back, there are excellent standards and engineering
behind them. No point in starting a web debate, but I'll just say I meant
"hack" in the way it glues together an abundant amount of technology and
most impressively, it works!

One thing's clear to me, I'll keep on using postgreSQL, it just makes me
smile,

Sincerely,
jon

On Friday 25. July 2008, Christophe wrote:

>Most developers don't make deep informed decisions about PHP vs other
>languages.  They use it because everyone else is, there is a huge
>ecosystem of support around it, it's easy to get something flopping
>around on the table quickly, and they know *for sure* that they can
>host it anywhere.  Which, really, are not terrible reasons to pick a
>development environment.

My 2 cents: The prime reason for the popularity of PHP is probably the
very gentle learning curve. You can start with a static HTML page, and
introduce a few PHP snippets to show dynamic content. For us
self-taught people, that means that you get instant results with
minimal work.

If any language want to compete with PHP in popularity, I believe that
it must be just as easy to mingle with HTML. $DEITY, I would love to be
able to include Perl code in a HTML page inside a pair of <?pl and ?>
tags.

Now, I don't write PHP scripts like that anymore. I like to have every
single character served as HTML to be generated by a function. And I
realize that Perl would do that even better than PHP. But as I have
become quite proficient with PHP, I tend to keep using that. It surely
does the job.
--
Leif Biberg Kristensen | Registered Linux User #338009
Me And My Database: http://solumslekt.org/blog/
My Jazz Jukebox: http://www.last.fm/user/leifbk/

On Fri, Jul 25, 2008 at 1:47 PM, Leif B. Kristensen <leif@solumslekt.org> wrote:
> On Friday 25. July 2008, Christophe wrote:
>
>>Most developers don't make deep informed decisions about PHP vs other
>>languages.  They use it because everyone else is, there is a huge
>>ecosystem of support around it, it's easy to get something flopping
>>around on the table quickly, and they know *for sure* that they can
>>host it anywhere.  Which, really, are not terrible reasons to pick a
>>development environment.
>
> My 2 cents: The prime reason for the popularity of PHP is probably the
> very gentle learning curve. You can start with a static HTML page, and
> introduce a few PHP snippets to show dynamic content. For us
> self-taught people, that means that you get instant results with
> minimal work.

For me I came from a C background, with bits of Pascal, and old Line
numbered BASIC (Hey, it's all we had on our govt spec Burroughs
systems in 1985).  the reason I picked php back in the day was that it
was a lot like C, a little like perl (the parts I like) and it had a
small enough memory footprint I could run a decent server with pgsql
6.5.3, apache 1.3.4 and php 3.0.5 on a 64 Meg RAM P-100 when
everything else I'd tried just crashed and burned or ground to a halt
on that poor little machine.

Years later and we build php servers with 8 Gigs ram, use memcached,
and other cool tricks to make them even faster.  But for all the "bad
engineering" in php's code base, I've never had a problem building a
stable server with it.  As long as I left out any mysql libs.  :)

> Well no PHP is conceptual undisciplined and confusing. I would
> not compare this with Postgresql itself which is very professional
> developed with a great vision. PHP is just and always was a hack.

I didn't mean to compare PG and PHP at the level of engineering quality,
but to suggest that perhaps both suffer from people continuing to hold
rigid preconceptions about them based on how things were 5 or 10 years ago.

Anyway, while I'm quite happy to continue banging out things that "just
work" in PHP for the time being, you suggest (in a subsequent post) that
there is one scripting language in particular that you'd use ... might I
enquire which language that is, and why? Just curious, I'm definitely
not looking for an ideological debate.

Re the possible heightened level of animosity to PHP in PG circles, if
it exists, could it have anything to do with PHP's close association
with MySql? The animosity, by the way, seems to go both ways, I think I
saw something about Rasmus Lerdorf bagging PostgreSQL on Slashdot(?)
recently. Personally, I'm not overly concerned either way. I'm happy to
leave the academic debates to those with the time to pursue them.

I'm the first to admit I know little about the art and science of
relational database design and admin. But up to this point, I haven't
needed to. It doesn't take rocket science to store and retrieve some
text for a few web pages in a database.

Anyway, this is proving an interesting, lively and helpful community,
hope to learn lots more about doing things the PostgreSQL way ... with
PHP :-).

Mick

On Sat, 2008-07-26 at 11:13 +0930, admin wrote:

> Anyway, while I'm quite happy to continue banging out things that "just
> work" in PHP for the time being, you suggest (in a subsequent post) that
> there is one scripting language in particular that you'd use ... might I
> enquire which language that is, and why? Just curious, I'm definitely
> not looking for an ideological debate.

You do realize that you just opened one of the longest, loudest and most
inherently beer inducing arguments known to man since Emacs vs Vi?
(answer: Joe) So why not! I use Python. I love Python. Although I
guarantee you that others will say ruby, perl, java (well maybe not
java).

The answer to your question is:

Use what works for you.

I used PHP for years, I actually used Perl before PHP but got tired of
the Perl oddness. I moved on to Python and love it. There are things in
it I don't like (just see subprocess) but for the most part, its
gorgeous.

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Hi,

Aarni Ruuhimäki wrote:
> On Friday 25 July 2008 15:33, you wrote:
>> I would avoid that in favour of using $HOME/.pgpass
>>
>> http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
>>
>> HTH
>> Tino
>
> Hi,
>
> Quite right you are. Or something like this?
>
> require("/eg/unknown_path/deep_somewhere_else/dbconnect_app_name.php")

Well this would be reinventing the wheel and also can really
cause accidently checking that into your version control system
which should be avoided for credentials holding files.

T.

Joshua D. Drake wrote:
> On Sat, 2008-07-26 at 11:13 +0930, admin wrote:
>
>> Anyway, while I'm quite happy to continue banging out things that "just
>> work" in PHP for the time being, you suggest (in a subsequent post) that
>> there is one scripting language in particular that you'd use ... might I
>> enquire which language that is, and why? Just curious, I'm definitely
>> not looking for an ideological debate.
>
> You do realize that you just opened one of the longest, loudest and most
> inherently beer inducing arguments known to man since Emacs vs Vi?
> (answer: Joe) So why not! I use Python. I love Python. Although I
> guarantee you that others will say ruby, perl, java (well maybe not
> java).

I'd say python too but I intentionally left that out in the discussion
just to avoid that usual foo vs. bar discussion which isn't to win.

> The answer to your question is:
>
> Use what works for you.
But this might as well include that you know if that really works for
you instead of beeing something that you stumble over and hope it will
work (because it seems to work for so many others)

> I used PHP for years, I actually used Perl before PHP but got tired of
> the Perl oddness. I moved on to Python and love it. There are things in
> it I don't like (just see subprocess) but for the most part, its
> gorgeous.

Yeah, I used C (for the web), i tried perl and came to python. Whenever
I checked PHP I found it so bad designed (if at all) that it really
hurted. And occassionally I'm asked for help on PHP questions so I see
nothing essentially has changed on the matters for the last 10 years.
Its still confusing naming of functions (hello namespaces), not really
a type system (think '1' + 2 ) and the like. PHP5 didn't change much
because if you want to adopt OOP you could as well just use a language
which does this for years (even Ecmascript) or - as most seem to do -
just continue to code old style. This horrible mixing of code and HTML
is even found in JSP code these days.

T.

Leif B. Kristensen wrote:
> On Friday 25. July 2008, Christophe wrote:
>
...
> My 2 cents: The prime reason for the popularity of PHP is probably the
> very gentle learning curve. You can start with a static HTML page, and
> introduce a few PHP snippets to show dynamic content. For us
> self-taught people, that means that you get instant results with
> minimal work.

Seems you never used a decent template engine, such as TAL
http://www.owlfish.com/software/simpleTAL/tal-guide.html

Which really is "code by example" instead of intermixing language
constructs with HTML which is incredibly hard to maintain.

> If any language want to compete with PHP in popularity, I believe that
> it must be just as easy to mingle with HTML. $DEITY, I would love to be
> able to include Perl code in a HTML page inside a pair of <?pl and ?>
> tags.

Most if not all other languages which are used for the web do have
those ways, which does not mean its recommended to do so.

> Now, I don't write PHP scripts like that anymore. I like to have every
> single character served as HTML to be generated by a function. And I

Which is for sure very performant ;)

> realize that Perl would do that even better than PHP. But as I have
> become quite proficient with PHP, I tend to keep using that. It surely
> does the job.

And hope that you arent bitten by nasty bugs in the language
implementation or your security configuration of it :-)

Ok, enough PHP bashing. Sun is shining here and so I invite everybody
to enjoy the weekend :-)

T.

On Fri, Jul 25, 2008 at 4:29 PM, Bill Wordsworth
<bill.wordsworth@gmail.com> wrote:
> years. It is newbies like him and fan-boys of Ruby/Python/Perl who
> give PHP a bad name. But I fail to understand the little animosity
> within some PostgreSQL users to PHP- is it the LAMP stack?

On Fri, Jul 25, 2008 at 4:59 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> I too don't get the animosity.  it's not like you can't write bad code
> in perl, java, ruby or python.
> The real issue is the quality of the programmer.

On Sat, Jul 26, 2008 at 1:43 AM, admin <mick@mjhall.org> wrote:
> Re the possible heightened level of animosity to PHP in PG circles, if it
> exists, could it have anything to do with PHP's close association with
> MySql? The animosity, by the way, seems to go both ways, I think I saw
> something about Rasmus Lerdorf bagging PostgreSQL on Slashdot(?) recently.

Yes let's stop bluffing and come out with the *real* reason: PHP/Zend
better support MySQL and both have scratched each others back via the
famous LAMP stack. But instead of thinking of better ways for
cooperation, this has caused certain jealousy in some circles,
something like "But I am so much better and so I should have enjoyed
that fame. This is not fair!". And *that* is the real reason why any
question on PHP on this list never goes without a shot at PHP.

PHP is faster than Python, has a smaller memory foot-print than
Python, has better SOAP features than Python, and is better suited for
the web than Python. Python is better suited for the
cli/mac/desktop/phone.

And nobody made Engineers the boss of us. We also can't compare
Database v Language, that MySQL = PHP where PostgreSQL = Language of
Your Choice. We can like PHP *and* PostgreSQL and stand up for both.
Cheers, Bill

On Sat, Jul 26, 2008 at 11:28 AM, Tino Wildenhain <tino@wildenhain.de> wrote:
> Leif B. Kristensen wrote:
>>
>> On Friday 25. July 2008, Christophe wrote:
>>
> ...
>>
>> My 2 cents: The prime reason for the popularity of PHP is probably the
>> very gentle learning curve. You can start with a static HTML page, and
>> introduce a few PHP snippets to show dynamic content. For us self-taught
>> people, that means that you get instant results with minimal work.
>
> Seems you never used a decent template engine, such as TAL
> http://www.owlfish.com/software/simpleTAL/tal-guide.html
>
> Which really is "code by example" instead of intermixing language
> constructs with HTML which is incredibly hard to maintain.
>
>> If any language want to compete with PHP in popularity, I believe that it
>> must be just as easy to mingle with HTML. $DEITY, I would love to be able to
>> include Perl code in a HTML page inside a pair of <?pl and ?> tags.
>
> Most if not all other languages which are used for the web do have
> those ways, which does not mean its recommended to do so.
>
>> Now, I don't write PHP scripts like that anymore. I like to have every
>> single character served as HTML to be generated by a function. And I
>
> Which is for sure very performant ;)
>
>> realize that Perl would do that even better than PHP. But as I have become
>> quite proficient with PHP, I tend to keep using that. It surely does the
>> job.
>
> And hope that you arent bitten by nasty bugs in the language
> implementation or your security configuration of it :-)
>
> Ok, enough PHP bashing. Sun is shining here and so I invite everybody
> to enjoy the weekend :-)
>
> T.
>

Bill Wordsworth wrote:
...

> PHP is faster than Python, has a smaller memory foot-print than
> Python, has better SOAP features than Python, and is better suited for
> the web than Python. Python is better suited for the
> cli/mac/desktop/phone.

Do you have proof for that? Or is this similar to "MySQL is faster then
Postgresql"? I see a different picture:

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=python&lang2=php

> And nobody made Engineers the boss of us. We also can't compare
> Database v Language, that MySQL = PHP where PostgreSQL = Language of
> Your Choice. We can like PHP *and* PostgreSQL and stand up for both.
> Cheers, Bill

Oh, we can do that exactly the same way as someone can stand up for a
... err.. whatever language ;-)

T.

Tino Wildenhain wrote:
> Bill Wordsworth wrote:
> ...
>
>> PHP is faster than Python, has a smaller memory foot-print than
>> Python, has better SOAP features than Python, and is better suited for
>> the web than Python. Python is better suited for the
>> cli/mac/desktop/phone.
>
> Do you have proof for that? Or is this similar to "MySQL is faster then
> Postgresql"?

I can't say that I am getting the same high off the drug Bill is using.
PHP may be faster in some circumstances (I really can't say) but better
SOAP features? Highly doubtful. Not to mention nice little things like REST.

But then again, this wasn't supposed to be a PHP vs everybody thread. I
find it interesting that Bill is being so negative. Most of the people
on the thread have just pointed out, specific issues with PHP that
Python (or insert other language here) does not have.

Sincerely,

Joshua D. Drake