The library still needs a flexible mechanism for thread synchronization, particularly when it comes to connections.
In most cases, concurrent const operations on objects don't interfere with one another and concurrent operations on one object often do not affect operations on another. The most notable exception is that many operations on other objects will interfere with the connection object they are related to.
To allow client programs to deal with this, a template parameter will be added to the basic_connection template that lets the client program specify a custom synchronization class. Options would include no-op synchronization for single-threaded programs; locking synchronization for complex multithreaded programs; and a cheap "debug class" that only detects and reports thread-safety errors.
Another, more awkward case is reference-counting in the PQAlloc-derived classes such as binarystring and result. This could be quite awkward; we'll have to look long and hard at possibilities for lock-free algorithms.
One low-overhead "synchronization" class could merely keep track of the last thread, function, or object to modify each protected object so as to detect race errors.
