jtv/libpqxx 7.6.0

libpqxx 7.6.0: removing a string conversion, but giving many things in return

on GitHub

Bad news first: I just removed the ability to convert a string to std::basic_string_view<std::byte>. I'm sorry: this conversion should never have existed and it's not safe to use. See bug #463. It's not safe because it leaves no object to "own" the converted data. The view points into deallocated memory. If this breaks your code, use std::basic_string<std::byte> instead — so string, not string_view.

Now for the good news, of which there is a lot:

• Add C++20 concepts: binary, char_string, char_strings.
• In C++20: generalise binary strings to any contiguous range of std::byte.
• Mark zview as a view and as a borrowed range.
• Save a copy step on string fields in stream_to.
• New helper: pqxx::value_type<CONTAINER>.
• New helper: pqxx::binary_cast. (#450)
• Some escaping functions now have "into my buffer" variants.
• More generic escaping functions, supporting more types of binary.
• In C++20, accept generic columns list for stream_to. (#447)
• Renamed <pqxx/prepared_statement> to <pqxx/params>. (Old name still works for now, of course.)
• Deprecated dynamic_params in favour of params.
• pqxx::params::append_multi() now calls reserve() if possible.
• pqxx::params::size() is now noexcept (but sadly, ssize() is not — because std::ssize() isn't).
• Helper for generating parameter placeholders $1, $2, etc. (#443)
• Now requires support for C++14 [[deprecated]] attribute.
• Deprecated unesc_raw() in favour of unesc_bin() variants.
• Once unesc_raw() is gone, we'll support only the hex escape format for binary data.
• Work around broken thread_local in MinGW gcc < 11.1.
• pqxx::blob now supports std::filesystem::path.
• Fixed check against header/lib version mismatch: check_pqxx_version_7_6
• More complete documentation, of cursors in particular.

Finally, "result slicing" is now deprecated. It will go away in the future. Was anyone using this? It never felt complete or useful to me, and I haven't heard anyone mention it in at least a decade. Once we get rid of it, that'll shave a tiny bit of complexity out of your inner loops and make them a little more efficient. The main reason though is simplicity. Simpler code means fewer mistakes and surprises.