then the protocol support is not needed.
-== How to use prepared statements with PgBouncer? ==
+== How to use prepared statements with session pooling? ==
-These tricks are mostly needed for JDBC which just loves them.
+In session pooling mode, the reset query must clean old
+prepared statements.
-=== Session pooling with PostgreSQL 8.3 and newer ===
+
+=== Cleaning prepared statements on PostgreSQL 8.3 and newer ===
This is easy - just set `server_reset_query = DISCARD ALL;`
or at least to `DEALLOCATE ALL;`
-=== Session pooling with PostgreSQL 8.2 and older ===
+=== Cleaning prepared statements on PostgreSQL 8.2 and older ===
This is problematic as older versions of PostgreSQL do not allow
easy way to drop prepared statements. Luckily there is system
server_reset_query = RESET ALL; SET SESSION AUTHORIZATION DEFAULT; SELECT deallocate_all();
-=== Transaction pooling ===
+== How to use prepared statements with transaction pooling? ==
To make prepared statements work in this mode would need PgBouncer
to keep track of them internally, which it does not do. So only way to
keep using PgBouncer in this mode is to disable prepared statements
-completely.
+in the client.
+
+=== Disabling prepared statements in JDBC ===
The proper way to do it for JDBC is adding `prepareThreshold=0`
parameter to connect string. But current JDBC code ignores
http://pgfoundry.org/pipermail/pgbouncer-general/2010-February/000507.html[]
+=== Disabling prepared statements in PHP/PDO ===
+
+To disable use of server-side prepared statements, the PDO attribute
+`PDO::ATTR_EMULATE_PREPARES` must be set to `true`. Either at connect-time:
+
+ $db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true));
+
+or later:
+
+ $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
+
+
== How to upgrade PgBouncer without dropping connections? ==