[Libpqxx-general] 3.0 --- compatibility with 2.6.9?

[Jeroen Vermeulen]

Carlos Moreno wrote:

Hi Carlos,

> Seeing the announcement for version 3.0 got me a bit worried
> about this issue of compatibility with existing code that has
> been working with 2.6.9

The only things you lose that weren't (IIRC) marked as deprecated all 
this time are cursor and cachedresult.  Programs using anything else 
that wasn't marked deprecated should recompile against 3.0 without problems.

If your application still builds against libpqxx 3.0, it should also run 
without changes and give the same results.  The incompatibility is a 
compile-time one, not a run-time one.


> When talking about cursors and cachedresults, Jeroen mentions
> something about any pains due to incompatibilities being worth,
> given the better quality of the new implementation --- not being
> quite familiar with these cursors, it was my understanding that
> this was an implementation detail  (a "behind the scenes" thing
> from the point of view of applications that link against libpqxx),
> and that client code deals with either iterators, or array-like
> subscripted access to the data.

That was just one of the options for dealing with cursors: using cursor 
streams/iterators.  Those APIs are still as they were in 2.6.9 (though 
3.0 improved the implementation underneath) and should work unchanged.

But the classes cursor and cachedresult are no longer there at all.  So 
if you used those, you'll now get big compiler warnings about undefined 
classes and need to re-do the code that used them.  That is the pain I 
was referring to.


> Any comments on this?   Well, or any other caveats or red-flags
> related to installing pqxx 3.0 as a "drop-in replacement" for
> 2.6.9 ?   (I will do a series of testing before installing on our
> production systems, of course, but I'm hoping I'll get any
> necessary heads-up, if any)

You do need to recompile your application to link with the newer libpqxx 
binary, of course.  But any incompatibility should show up at compile 
time, not at run time.

In fact that was the concluding argument for ripping out the old cursor 
class: its behaviour in complex back-and-forward scenarios was messy and 
probably incorrect.  Fixing that, if possible at all, might have broken 
existing programs.  So I preferred the compile-time error over the risk 
of run-time failures.

The new cursor API makes it necessary to specify much more clearly what 
you want a cursor to do at any given time, which is annoying but which I 
think will also result in more maintainable code.


Jeroen