Chapter 1. Why another C++ SQL library?

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:

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.

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.