Brandon is spot on here. If you're not having performance issues, pconnect is dangerous. Primarily the issue is the way PHP handles persistant connections.
The skinny is that you have to have your database setup for more max backends than you have apache front ends, or PHP/Apache will starve for connections to the database. The reason is that each pconnect connects to the database persistantly via a single apache child process. The connection doesn't go away until the child process is killed by the master apache process.
So, if you have apache setup for 150 max children, and postgresql set up for 75 max children, you will eventually run out of backends processes for apache to talk to.
Increasing the max number of postgresql backends can be hazardous, as each one eats a fair bit of memory, and having hundreds of idle backends sitting around causes some performance problems itself.
Plus, if your kernel params don't allow for enough file handles to be open, then apache/postgresql may not be able to open all the children you've set them up to open, and the users will start getting no output.
Dropping the max number of apache children may result in denied access to users if you routing have hundreds of simo accesses with keep alive and such turned on.
What would be nice is if PHP had a real backend pooling algorhythm that could create, say, two dozen connections, then pass them off to whichever script needed them then reuse them individually.
If you must use pconnect, make sure you have the memory / system resources to handle it, it's a memory hog.
