Re: Libpq++ interface for postgres 8.1 - Mailing list pgsql-interfaces

On Wed, December 21, 2005 22:16, Francis Reed wrote:
> We have implemented the libpq++ interface for earlier versions of postgres
> 7.x. We see that libpqxx is now the defacto.

I wouldn't say libpqxx was de facto; it's documented as the current C++
API (which I guess makes it de jure) and has been for several years.  But
that does not mean you'll be forced to migrate; you should still be able
to build libpq++ with current libpq versions or if that is not an option,
to continue using 7.x libpq versions with the latest backends.


> Anyone had any experience of converting one to the other we want to get a
> handle on the effort involved and some ideas on how to approach such a
> project

Depends a bit on what you do with it, of course.  In the ideal case, all
you need to do is provide a simple wrapper class that combines a
connection, a transaction (or nontransaction if you don't want atomicity),
and a result like the libpq++ connection classes did; and provides a few
simple wrapper functions like GetValue() that convert exceptions into NULL
return values etc.  Mostly libpqxx adds flexibility that libpq++ didn't
have, such as keeping a result set around after you've executed your next
query, while completely hiding the libpq API.  I'll assume that you're not
using 8.x features such as savepoints or "with hold" cursors.

Three potential roadblocks spring to mind:

1. Compiler.  Whereas libpq++ is pretty basic and doesn't use any
particularly advanced C++ features, libpqxx goes all-out with templates
and such.  So if you're using an unusually old or broken compiler then you
might run into trouble.  For gcc, updated editions of version 2.95 (first
released mid-1999) will still just about work but is likely to be left
behind by the upcoming libpqxx 3.0.  Visual C++ 2002 isn't good enough but
2003 is, IIRC.  Sun Studio 6 should work, but 5 is problematic at best.

2. SQL.  If what you do is just basic SQL statements such as INSERT and
UPDATE, and use what transaction bracketing libpq++ provides, no worries. 
That little wrapper class can easily take care of all that.  But things
get more complicated if you create transactions and/or cursors, listen for
trigger notifications, prepare statements, or set session variables using
direct SQL statements.  With libpqxx those features are wrapped in
specific classes and functions, sometimes with considerable extra
intelligence built in.  These should be used instead of raw SQL wherever
possible.  In most cases you should be able to get away with raw SQL, but
libpqxx wasn't really designed for that.  At least disable automatic
connection reactivation if you go this way; that should take care of most
or all surprises in this regard.

3. Errors.  Since libpqxx uses regular C++ exceptions to report errors,
you'll have to catch those and turn their embedded error information into
something useful.  That may work very differently from what you did
before.

As for approach, I'd suggest the following initial steps:

1. Try building libpqxx with your target compiler; then do a "make check"
to run the test suite.  If all that works, you'll be okay as far as your
compiler is concerned.  If there are actual test failures, complain about
them and we'll fix them; compiler compliance is the bigger hurdle here.

2. Make an inventory of the SQL commands your software executes, and
classify them by feature category: select/update/insert/delete,
transactions, stored procedures, cursors, prepared statements, large
objects, COPY functionality, triggers, session and transaction variables
(note that their transactional semantics changed a bit somewhere around
7.4), and so on.  Incidentally this also comes in handy if you want to
survey DBMS portability of your code.

3. Also, try to draw up a similar list of things you do that are more
intimate with libpq++: do you retrieve the connection's file descriptor
and if so, what do you do with it?  How far do you go in extracting
information about errors, and in what forms does that information flow
into your program?  Do you invoke any libpq functions directly?  For this
list, try to keep track of the respective purposes of these interactions.

You'll then have to compare the lists you made to the libpqxx reference
documentation and see what can be supported as-is; what will require
restructuring; and what code you may have to ditch.  For instance, you may
find you've got some rarely exercised code for restoring broken
connections that nobody's quite sure how to maintain; libpqxx has that
functionality built in, so you'd want to excise this code rather than
trying to port it.  If you find that libpqxx offers a special-purpose
class or function for something you do, assume that you'll be using that
and see if it has any implications for your code.


Jeroen