Several open-source C++ wrapper libraries are available for various databases, as well as some database-independent ones; there's libpql++™, libpq++™, libsqlxx™ and so on.
So was libpqxx™ really necessary?
I think it is. The C++ Standard, and its standard library in particular, have stabilized over the mid-1990s; compilers and standard library implementations are still following suit at the time of writing. As a result, most older third-party libraries suffer from symptoms such as:
Not using exceptions. Many libraries return a status code and expect the caller to check for errors "if he's interested." Of course he's interested. But checking each and every call is tedious and error prone.
Ad-hoc exception classes. Programs using C++ libraries need to deal
with various incompatible exception class hierarchies, and error
handling becomes a total nightmare with multiple essentially identical
catch clauses for every try block.
Ad-hoc string classes. As one member of the C++ standards committee put it, if the C++ wasn't going to have a standard string class, "there will be blood in the streets." Luckily, the committee saw the wisdom in this, and civilization was spared.
"A Better C." Using only the oldest features of C++ as extensions to the C language really only complicates things, but there was a time when this was the only way to write portable C++.
Ad-hoc containers and algorithms. Inventing your own container APIs, interesting as it may be, in most cases is wasted development effort. Besides that, there's also the redundant effort of having to learn how they work.
For these reasons, third-party libraries have tended to grow into intrusive frameworks. Third-party code, and class libraries in particular, need to be rewritten to replace such ad-hockery with the rich and standardized functionality now provided by C++. This is what libpqxx™ intends to do for PostgreSQL™. The library was designed to be a forward-looking one, which means that ports to vendor X's compiler Y may have to wait until X improves its support of the Standard.
But there were other reasons to design a new SQL frontend from scratch. C++ is a complex language, and the only things stopping a library writer from shooting himself [1] in the foot are years of experience and an extensive idiom of good practices. To name a few typical symptoms of foot-shooting:
Poor language integration. Users need to learn myriads of function names when standard C++ operators can be overloaded instead to make code fit in more naturally with the core language.
Overdoing overloading. It's also easy to go overboard with operator or function overloading, and many classes do. Some programmers use identical function names to mean very different things, or define operators whose semantics are not clearly derived from their conventional meanings.
Resource management. In the complex world of C++, what the user really needs from a library is a little help in ensuring that objects are deleted at the proper time, pointers don't go off into never-never land, and so on. Perhaps the most compelling usage of C++ is the "resource acquisition is initialization" paradigm, but too few libraries apply it as yet.
Convoluted family trees. Class derivation is a beautiful thing, but it can be overused. Some libraries construe far-fetched relations between classes, or needlessly expose "convenience" relations using public inheritance.
Overweight classes. Some classes lump together different pieces of functionality with different lifetimes. For instance, some C++ SQL libraries integrate transaction bracketing into a connection class. Yet it is not unreasonable for an application to perform multiple consecutive transactions using the same connection.
Exposure of low-level interfaces. Some C++ wrappers for C-level SQL interface libraries (including libpq++™) don't hide the ugly details of the underlying API. Worse, some only provide "utility" classes that the user can mix in freely with C-level function calls.
Again, libpqxx™ is an attempt to do better. Hopefully this has resulted in a library that is easier to use than most alternatives while giving you more flexibility, that helps you avoid common pitfalls and reduces the need for debugging.
[1] Yes, himself. A "writer" is grammatically masculine, unless actual gender is known and definite.