Skip to content

6.3.0: Encodings, new stream classes, deprecations, and more.
Compare
Choose a tag to compare
@jtv jtv released this 02 Feb 21:45
· 1657 commits to master since this release
6.3.0
d6ffb1a

This is a big release, with lots of changes. It paves the way for some even more drastic changes to come in 7.0.

First let me tell you what's new in 6.3, and then I'll go into my plans for 7.0.

What's new in 6.3

Thanks to some major contributions from Joseph "JadeMatrix" Durel, we now have:

Type-safe replacements for tablereader and tablewriter: stream_from and stream_to. They support tuples (or tuple-like types) to represent database rows on the client side, so you could stream a std::tuple or std::vector straight into a database row, or vice versa.

Broader support for variable-width multibyte client encodings. UTF-8 has always worked, but other encodings such as SJIS might confuse the code by embedding bytes that looked like ASCII quotes or backslashes and such inside a multibyte character. From now on, the library should work properly with all client encodings that PostgreSQL supports.

In other news:

  • libpqxx lets you assign names to some types of objects, such as cursors or transactions. These names are now more tolerant of "special" characters such as embedded quotes or non-ASCII letters.
  • The CMake build has been overhauled. There may be teething problems, so please report anything you run into.
  • Copying result objects for long SQL queries is now faster.

For the really big changes though, we're going to have to break stuff. Many items have also been deprecated. See the section on my 7.0 plans below.

Also, many items which had been documented as being deprecated are now actually marked deprecated, using the C++ deprecated attribute if your compiler supports it. This means that you may start seeing warnings where your code has been using deprecated features. Those features really will start disappearing in 7.0.

Preparing for 7.0

We'll see some profound change in libpqxx 7.0. Some of details still have to be worked out, but in 6.3 you'll start seeing deprecation warnings for features that will no longer work as before.

What can you expect from 7.0? What will you need to be ready for? Read on.

C++ upgrade

C++11 has been great, but now I want more. There are some wonderful things we can do if we bump the minimum requirement to C++17. Is your compiler ready for them?

The C++17 features I'd particularly like to use are:

  • std::optional as, eventually, the one standard way to accommodate null values.
  • Nested namespaces. It'll make pqxx::internal easier for me to manage.
  • std::string_view support in places where we already accept std::string or C-style strings.
  • std::to_chars and std::from_chars could replace a lot of libpqxx code.

If your compiler is not ready for any of these new features, please file a bug on the ​Github page so I can avoid breaking your build.

Connection classes

The connection class hierarchy is going to change drastically. If you have defined your own custom connection classes, these will no longer work, and you will start to see deprecation warnings in libpqxx 6.3. The new design is not final, but it will be a lot simpler than what we have now. Some esoteric features are going to disappear, and in return you'll get a move constructor and a much easier class hierarchy to work with.

The plan is to fold essentially the entire class hierarchy into one single class. It will support the current built-in connection types, but it won't be extensible. We have always had an API for defining your own connection policies, and the library uses it to implement different types of connections, but I've never heard of anyone else using this API to define their own connection types. The existing built-in connection types will just be thin wrappers for the single connection class, and eventually the single connection class should replace them all.

Replacing lazyconnection and asyncconnection

If you're using lazyconnection or asyncconnection, the API will change. You'll have to do a bit of extra work.

In older libpqxx versions, you got a connection object which looks just like a regular connection but only completes its actual connection to the database once you actually start using it. Your code will have to go through an explicit check-or-wait step before using the connection. It may end up looking similar to std::future, or it may just be a member function. I'm not sure yet.

No more connection reactivation

It's just a fact of life: network connections to the database can break. It could happen because of a network problem, or the database may have been restarted. The existing connection classes hide this from you. They notice that the connection is broken and quietly try to re-establish it for you. This feature is going to be removed.

That may sound like a problem. But your application already knows how to deal with a broken connection, right? It may simply happen slightly more often.

I believe doing it this way will make the application design issues clearer, eliminate a duplication of effort between libpqxx and your application, and clear out some dark corners where bugs might hide. It will also remove an enormous source of complexity inside the connection classes.

As a bonus, several operations on connection objects can finally get the const qualifier. That's because they will no longer try to re-establish a broken connection, or finalise an incomplete lazy or asynchronous connection. It will be a lot more obvious which operations make changes to your connection and which ones will not. Some references in your code that don't look like they modify the connection may even become const.

Assets 2
Loading