jtv/libpqxx 8.0.0-rc5

libpqxx 8.0.0 release candidate 5

on GitHub

Yes, it's another release candidate! I promise, it's not that there were bugs or anything, just that things kept getting better. The problem with maintaining backwards compatibility across minor releases is that a major release is the one opportunity for all sorts of structural changes. So any big improvements have to go in now or wait, possibly for years.

Unless any major problems show up, this should be the last release candidate before the big 8.0 release. Exciting times! I can't do a lot in a day at the moment, so any release is a big deal for me.

Here are the main changes:

You can now combine connection string & option pairs on connections! (#1133)

This feature was contributed by @serpent7776. It lets you pass both a connection string and a series of individual parameters. Once we had this, it became possible to simplify the web of constructors.

Various zview changes:

• You can no longer construct a zview from a null pointer.
• The zview class is now final.
• There is now an implicit conversion to a C-style string (char const *).

The libpqxx exception classes now have a C++26 std::stacktrace, if available.

This means your application can log a full traceback when libpqxx throws an exception, just like in other languages.

Be aware though that this exists only for exceptions that libpqxx throws. If some standard library function throws an exception of its own from within libpqxx code, that is still the standard exception and there's no traceback.

The "config-*" headers in the build are now simpler. (#1152)

You may never even notice this but oh, it got so much better!

• There is now only one of those headers: config-compiler.h.
• The CMake build now filters out unneeded macros from that header, like the autotools build does.
• There is no more config-autotools.h.

It looks like we worked around a regression in Microsoft Visual Studio 2026. (#1160)

It's strange: MSVC 2026 failed to accept a run-of-the-mill concept-based partial template specialisation that MSVC 2022, gcc, and clang all accept. And it's not a new language rule or anything: the MSVC error actually looks to have existed for much longer.

Deprecated extract_version.sh.

Use extract_version.py instead. It has a few extra features, such as the ability to extract a patch-level version number, and a numeric patch-level version number which evaluates to -1 for release candidates and such.

Rewrote header/binary version compatibility check.

There is a bit of code in libpqxx that checks that you're not linking your application binary with a libpqxx version for which it was not built. In most cases when you mismatch versions, the library will probably fail to link at all and this check won't even run. But there are some scenarios where this may detect problems early, for example if they're the same major and minor version but your libpqxx binary has a lower patch level than the one for which your application was built.

For stream(), a type must be convertible and move-constructible. (#1168)

Actually this requirement already existed, at least in C++20 builds, but now it is an explicit requirement in the code, enforced through a concept. Yay C++20!

The build defaults to C++20 minimum.

In recent versions, most of you needed to tell your compilers which C++ version to use when building libpqxx. The tooling wasn't quite there to automate this the way I wanted it, but now it is. You can specify a specific C++ version, but if you don't, libpqxx will automatically compile with the minimum C++ version required. For libpqxx 8.0, that means C++20.

Please try out this new release candidate, and let me know if you run into any trouble!

Actually, also let me know if you don't run into any trouble. 😆 It'll help me release more confidently, and perhaps sooner.