wiki:WikiStart

Version 76 (modified by jtv, 12 years ago) (diff)

--

Welcome! libpqxx is the official C++ client API for PostgreSQL, the enterprise-strength open-source database software. (If "PostgreSQL" is too verbose, call it by its shorter name, postgres).

If you are writing software in C++ that needs to access databases managed by postgres--on just about any platform--libpqxx is the library you use. The source code is available from here, although in most cases you'd normally work with pre-built binary packages provided by a package maintainer for your specific platform, and distributed through your normal package management infrastructure.

For those who arrived at this page through http://pqxx.tk/: that domain name may disappear at some point in the future. Please use http://pqxx.org/ instead.

2007-08-13 Mailing lists moving!

The libpqxx-announce and libpqxx-general mailing lists are moving. The old GBorg site is being decommissioned in favour of a more modern replacement called pgFoundry.

If you wish to stay on these mailing lists, please follow the links above to subscribe to their new incarnations.

2007-04-24 "Visibility" errors in Red Hat-derived gcc

If you're using a GNU/Linux system using a gcc derived from Red Hat's version (Fedora, CentOS, ...), you may see build failures involving "-fvisibility." As far as we can make out this is a bug in a compiler bug; see bug ticket #83 for help with this situation.

2007-02-07 Spaces in Windows directory paths

When building libpqxx 2.6.9 on Windows using the provided Makefiles, the path to the PostgreSQL source should not contain any spaces. See bug ticket #105 for details.

2007-02-03 Visual C++ problems with 2.6.9

Trigve Siver has found two problems building libpqxx 2.6.9 with Visual C++:

  1. The lib directory is not created. Workaround: "mkdir lib" before you start your build.
  2. A workaround for a Visual C++ bug specifies an incorrect namespace for disable_noticer. See bug tickets #106 and #122. Workaround: edit src/tablewriter.cxx (line 41), src/tablereader.cxx (line 49), and include/pqxx/trigger.hxx (line 70). In each you'll find a mention of internal::disable_noticer. Each of those should be plain "disable_noticer," without the "internal::" qualification.

Finding Everything

Where What
Sales Pitch Why this library should interest you
Using This Site The various services offered by this development site
Download Page Source archives (no binaries; those depend on your individual platform)
FAQ Frequently Asked Questions, and their answers
Online Documentation Wiki and copies of packaged documentation
Packagers Page Information for maintainers of libpqxx packages
Bug Tracker Known bugs and requests (as in View Tickets option in top button bar)
Bugs by Milestone Bugs and feature requests, but ordered by milestone
Reporting Bugs How to report a problem or request a new feature
Mailing Lists libpqxx-general and libpqxx-announce (hosted on pgFoundry site)
Other Projects Other open-source development projects hosted here
libpqxx Elsewhere Sites where libpqxx is registered as a project
Author and Contributors Who made all this?

For issues not suitable for the mailing list or bug tickets, contact the author at jtv@xs4all.nl.

Also, you may want to have a look at the other open source projects hosted on this site.

Technical Overview

This library works on top of the C-level API library, libpq. You will need libpq in order to use libpqxx.

The first thing you're likely to notice in programming with libpqxx is that unlike other libraries, it revolves entirely around transactions. Transactions are a central concept in database management systems, but they are widely underappreciated among application developers. Another well-known open source database system, MySQL, never even got around to implementing them at all in their own engine, relying on a third-party replacement engine (now owned by Oracle) to provide this functionality instead.

It may sometimes be possible to build limited applications reliably without serious use of transactions. More usually, however, applications are designed without transactions simply because the developers aren't aware of the risks they are taking, and any data loss is rare or small enough not to be noticed. That kind of design was not considered acceptable for libpqxx.

With conventional database APIs, you issue commands and queries to a database session or connection, and optionally create the occasional transaction. In libpqxx you start a transaction inside the connection first, do your SQL work using that transaction, then commit the transaction when it's complete. There are several types of transactions with various "quality of service" properties; if you don't really want to use transactions at all, one of the available transaction types is called nontransaction. This transaction type provides classic, nontransactional behaviour.

Every command or query issues a result object, which is really a smart pointer so it can be copied around without incurring much cost in terms of performance. No need to write special code to check these for success; error conditions are converted to regular C++ exceptions. Result objects can be kept around for as long as they are needed, completely separate from the connections and transactions that originated them.


Ohloh Metrics GTF Contributor