Обсуждение: Libpq++ interface for postgres 8.1
We have implemented the libpq++ interface for earlier versions of postgres 7.x. We see that libpqxx is now the defacto. 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 Thanks! _____________________________________________ Francis Reed Software Development Manager Tel: + 353 1 449 1900 DDI + 353 1 449 1981 Fax: + 353 1 449 1901 Mobile + 353 87 859 7785 Email: freed@iel.ie <mailto:freed@iel.ie> Web Site: http://www.interactive-enterprise.com The Interactive Enterprise Limited 7 Riverwalk National Digital Park CityWest Business Campus Dublin 24 Ireland
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
Jeroen T. Vermeulen wrote: >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. > > > Speaking of libpqxx has anyone noticed that if you go to the website you are presented with big old banner and you have to actually click: Continue to PQXX.TK: libpqxx - Open-Source C++ database API for PostgreSQL <http://gborg.postgresql.org/project/libpqxx/genpage.php?about> Or you can wait 15 seconds... Not to mention the popup window... Not very cool. Or presentable as a C++ api for the world's most advanced open source database. Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Thu, December 22, 2005 01:37, Joshua D. Drake wrote: > Speaking of libpqxx has anyone noticed that if you go to the website you > are presented with big old banner and you have to actually click: Ouch. Looks like the .tk people got a bit more aggressive in pushing their paid service. Guess I'll have to pony up after all... Thanks for bringing it up. Jeroen
Jeroen T. Vermeulen wrote: >On Thu, December 22, 2005 01:37, Joshua D. Drake wrote: > > > >>Speaking of libpqxx has anyone noticed that if you go to the website you >>are presented with big old banner and you have to actually click: >> >> > >Ouch. Looks like the .tk people got a bit more aggressive in pushing >their paid service. Guess I'll have to pony up after all... Thanks for >bringing it up. > > CMD would be more then happy to host a libpqxx site for free providing it was actually for the community. Joshua D. Drake > >Jeroen > > > >---------------------------(end of broadcast)--------------------------- >TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Thu, December 22, 2005 01:56, Joshua D. Drake wrote: > CMD would be more then happy to host a libpqxx site for free providing > it was actually for > the community. Actually it's currently hosted on GBorg, not on .tk; pqxx.tk is just an alias. But I'm considering moving development over to http://thaiopensource.org/development/ (these projects are all running on Trac and Subversion, which I've come to love) and then moving pqxx.tk to point at that. The URL would also be simple enough that I could let the pqxx.tk alias slip. Still, all options are welcome. I'm not sure what the proviso means exactly, though: the code is obviously for the community, and apart from that, the level of actual community involvement seems mostly up to the available applications AFAICS: FTP is very one-way, anonymous CVS slightly less so, mailing lists can have any degree of openness to participation. Funny this should come up today, by the way, since today I got my first commercial spam in a GBorg bug ticket. :-( Jeroen
>Actually it's currently hosted on GBorg, not on .tk; pqxx.tk is just an >alias. But I'm considering moving development over to >http://thaiopensource.org/development/ (these projects are all running on >Trac and Subversion, which I've come to love) and then moving pqxx.tk to >point at that. The URL would also be simple enough that I could let the >pqxx.tk alias slip. > > > Well we use Trac for ALL of our development :) so if that is what you would like we would be happy to set it up for you. If we can help let us know, if not no sweat :) Sincerely, Joshua D. Drake >Still, all options are welcome. I'm not sure what the proviso means >exactly, though: the code is obviously for the community, and apart from >that, the level of actual community involvement seems mostly up to the >available applications AFAICS: FTP is very one-way, anonymous CVS slightly >less so, mailing lists can have any degree of openness to participation. > >Funny this should come up today, by the way, since today I got my first >commercial spam in a GBorg bug ticket. :-( > > >Jeroen > > > >---------------------------(end of broadcast)--------------------------- >TIP 6: explain analyze is your friend > > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/