Published by jtv over 5 years ago
This is a minor update to 6.4, the current stable release. It fixes the handling of const
in smart-pointer-like arguments to prepared/parameterised statements.
Published by jtv over 5 years ago
Fixes some puzzling CMake build errors. Turns out the problem was, sometimes there are still autoconf-generated config headers in the source tree, and the CMake build would prefer those over the ones which CMake itself had generated in the binary tree. Bad things would happen if the two contained incompatible configuration.
Also, uses pkg-config
if the pg_config
script is not available. Expect pkg-config
to become the default over time.
Published by jtv over 5 years ago
This release fixes two omissions with the new stream_from
and stream_to
headers:
pqxx/pqxx
header.The old tablereader
and tablewriter
headers are no longer included from pqxx/pqxx
. They're still there, but you won't automatically include them when you include pqxx/pqxx
. The stream_from
/stream_to
headers replace the tablereader
/tablewriter
ones, and the old headers will be gone completely in 7.0.
Published by jtv over 5 years ago
Well, that fix for a memory leak in 6.4.1 wasn't quite perfect. Yes, the memory got freed. But not in quite the right way for Windows, where you can't allocate memory in one DLL (in this case libpq) and free it in another (here, libpqxx). If you are using Windows, unescaping binary data in 6.4.1 will probably crash, and 6.4.2 should fix it. If you are not on Windows, or are not calling esc_raw
, you shouldn't notice any difference.
Thanks @egorpugin for spotting the problem and pointing it out so quickly!
Published by jtv over 5 years ago
It's been ages since I ran libpqxx through some solid memory checking tools. In this case, I enabled all gcc instrumentation I could find, and it turned up a few small leaks and a use-after-free!
Those are fixed now, so I recommend that you upgrade.
Published by jtv over 5 years ago
This release addresses (but does not fully prevent) a subtle lifetime bug. Due to an unexpected subtlety in how libpq and libpqxx interact, an application would access invalid memory if the following things all happened together:
result
object from a connection.result
.result
.result
which causes the underlying C driver, libpq, to issue an error or warning message.Today's update can't prevent this, but it further limits the circumstances under which this can happen. Now, the bug will only happen if the connection has an errorhandler
registered on it at the time it produces the result
.
Documentation has been updated to mention this as a hazard of registering an error handler. If you need to register an errorhandler
on a connection, you will need to keep the connection object alive until you stop using the result
you got from that connection.
Published by jtv over 5 years ago
Another exception change: if a connection's client encoding can't be read, the attempt will throw an exception.
Also, a few more CMake build problems are fixed.
Published by jtv over 5 years ago
It's mostly small fixes, but some of these changes may affect your application. So test carefully.
pqxx::failure
; always conversion_error
!using namespace std
.Published by jtv over 5 years ago
This is a minor update to 6.3.0, fixing a few build problems on Windows.
See the 6.3.0 release for the really interesting stuff!
Published by jtv over 5 years ago
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.
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:
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.
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++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.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.
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.
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.
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
.
Published by jtv about 6 years ago
Today marks 18 years since my initial commit in libpqxx's original CVS repo. This library is now officially a grownup.
Changes:
Published by jtv over 6 years ago
The build machinery now tries to cope with non-ASCII characters in paths. It's not perfect, because filesystem paths are raw bytes — it may still break if those raw bytes fail to decode to Unicode characters.
If your application's build breaks with an error about std::experimental
not existing, try defining the new macro PQXX_HIDE_EXP_OPTIONAL
. It will suppress libpqxx support for std::experimental::optional
. This can be needed if your copy of libpqxx was built in a compiler environment which had that template, and your application is being built in an environment which does not.
Published by jtv over 6 years ago
Thanks to all the people who contributed fixes and improvements!
Published by jtv over 6 years ago
Now that we're on github, libpqxx is getting a lot more scrutiny. Thanks to all those who submitted bugs and fixes!
This update mostly addresses compile issues, but also one actual bug: in some circumstances an error string would be left empty.
Published by jtv over 6 years ago
Adds a first-generation parser for SQL arrays. We'll want to improve on this later. See the pqxx/array
header.
This release also fixes some bugs which would break builds under specific circumstances — in some cases builds of the library, in other cases builds of client software. So, if you had trouble compiling with 6.0, try 6.1.
Dependencies between library headers have changed. It's possible that some code may need an extra #include
here or there, if your code implicitly relied on some libpqxx headers including other libpqxx headers.
Published by jtv almost 7 years ago
This is a major overhaul. Changes are everywhere:
shared_ptr
, noexcept
, etc.
configure.ac.in
; we now use configure.ac
directly.pqxx::items
. Use the new C++11 initialiser syntax.maketemporary
. We weren't using it.exec0()
: perform query, expect zero rows of data.exec1()
: perform query, expect (and return) a single row of data.exec_n()
: perform query, expect exactly n
rows of data.NOMINMAX
in headers.WSAPoll()
on Windows.Most old code should still compile against the new library, but you may find incompatibilities in uncommon usage.
Everything is more modern now. The code lives on GitHub (with automated test runs thanks to CircleCI), and documentation on ReadTheDocs. Release procedures were rigid and cumbersome and kept me from doing any releases at all; now they're light and fast again. I couldn't get access to the mailing lists, so I dropped them. A lot of workarounds for old compilers and postgres versions went out the window. As a result, the configure script runs in about as many seconds as it used to take minutes!
Adding exec1()
functions (to execute a query that returns exactly 1 row) may seem like trivia. But it's actually a big deal. Everything had to move and change in very painful ways in order to make that possible! A row
object now keeps its result
object alive, so you no longer need a result
somewhere in order to have a row
variable. The same thing happened between fields and rows. The side effect is that the library is now cleaner, and easier to reason about. To me, looking at the inside, it's like the whole library is new again.
For you, I hope it will mainly be simpler. There's less crud. Prepared statements and parameterised statements no longer look like a clever hack. Builds are faster. It's harder to make subtle mistakes.