libpqxx 8.0.0 release candidate 5

[jtv]

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, but it feels good when I can get something nice done.

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 path both a connection string and a series of individual parameters. Once we had it, it became possible to simplify the complex 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 onlyone 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 uild 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.

---

This discussion was created from the release libpqxx 8.0.0 release candidate 5.

[michaelaeriksen]

Testing on mac with clang and so far so good, but do you have an example of how to create a custom type with 8.0.0?

[jtv]

See include/pqxx/doc/datatypes.md !

It's a lot easier now, though I should still write some more on compound types and add testable example code in the new examples/ directory.

[michaelaeriksen]

Thanks! Got that working. Next issue is handling of arrays. How do I pass a std::vector<std::string> to params?

I have something like this

pqxx::params p;

std::vector<std::string> args;
args.emplace_back("42");

p.append(args);

When I run this I get Tried to read text without knowing its encoding. This used to work with old version passing args to a TEXT[] field

[jtv]

Yes, it was a tough one... Now that you can pass things like std::vector<std::string> as parameters, sometimes the library has to know the client encoding. And that was kind of difficult to work into the API without breaking compatibility. So I went for a somewhat pythonic solution

Off the top of my head, you can pass your connection or transaction object, or an encoding group, as the first constructor argument to pqxx::params. Should be in the documentation.

[pkfox]

@jtv @michaelaeriksen
Just my two penneth I tried this

pxxx::params Params(tx,id);
\\Params.enc was ascii safe
pxxx::params Params(id);
\\ Without the transaction object it was unknown
\\ Both worked though

[jtv]

Yes, that's the way it's supposed to work.

IIRC I could have made it just work in the usual case where encoding was just not relevant, but it increased the risk of some problems only showing up during production rather than in testing. So I opted to make it fairly strict.

But the tradeoff isn't quite as simple as I would have liked, so IIRC there's still ways to make it break at run time. There's a scala of options from very permissive with a risk of breakage at run time, to very strict and incompatible with existing code.

[pkfox]

Encoding was only ever a problem for me for

std::vector<std::string> 

which you fixed ages ago

[pkfox]

apologies for the formatting

[jtv]

Encoding was only ever a problem for me for std::vectorstd::string which you fixed ages ago

True, but it's an extensible API.