libpqxx 7.6.0: removing a string conversion, but giving many things in return
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 ofparams
. pqxx::params::append_multi()
now callsreserve()
if possible.pqxx::params::size()
is nownoexcept
(but sadly,ssize()
is not — becausestd::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 ofunesc_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 supportsstd::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.