pgpool-II
The oldest of the PostgreSQL compatible packages used for connection pooling that's still in development, pgpool-II improves on the original pgpool in a variety of ways: http://pgpool.projects.postgresql.org/.
Its primary purpose is not just connection pooling, it also provides load balancing and replication related capabilities. It even supports some parallel query setups, where queries can be broken into pieces and spread across nodes where each has a copy of the information being asked about. The "pool" in pgpool is primarily to handle multiple servers, with the program serving as a proxy server between the clients and some number of databases.
There are a few limitations to pgpool-II setup to serve as a connection pooler. One is that each connection is set up as its own process, similar to the database only re-used. The memory overhead of that approach, with each process using a chunk of system RAM, can be significant. pgpool-II is not known for having powerful monitoring tools either. But the main drawback of the program is its queuing model. Once you've gone beyond the number of connections that it handles, additional ones are queued up at the operating system level, with each connection waiting for its network connection to be accepted. This can result in timeouts that depend on the network configuration, which is never a good position to be in. It's a good idea to proactively monitor the "waiting for connection" time in your application and look for situations where it's grown very large, to let you correlate that with any timeouts that your program might run into.
Because of its replication and load balancing related features, for some purposes pgpool-II is the right approach even though it's not necessarily optimal as just a connection pool. pgpool-II supports what it calls master/slave mode, for situations where you have a master database that handles both reads and writes as well as some number of replicated slaves that are only available for reading.
The default replication software it assumes you're using, and only one available in older versions of the software, requires you have a set of databases all kept in sync using the Slony-I replication software. A common setup is to have a pgpool-II proxy in front of all your nodes, to spread the query load across them. This lets you scale up a read-only load in a way that's transparent to the application, presuming every node is qualified to answer every query.
Starting in pgpool-II 3.0, you can use this feature with the PostgreSQL 9.0 streaming replication and Hot Standby capabilities too. The read-only slaves will still be a subject to the limitations of Hot Standby described in the Chapter 14, Scaling with Replication. But within those, pgpool-II will handle the job of figuring out which statements must execute on the master and which can run against slaves instead.
As with the Slony case, it does that by actually parsing the statement that's executing to figure out how to route it. The way it makes that decision is covered in the pgpool-II documentation. This is one of the reasons pgpool-II is slower than pgBouncer, that it's actually interpreting the SQL executing. But as it enables the intelligent routing capability too, this may be worth doing.