Changes between Version 201 and Version 202 of WikiStart

Apr 28, 2019, 1:36:00 PM (9 months ago)



  • WikiStart

    v201 v202  
    55If you are writing software in C++ that needs to access databases managed by postgres—on just about any platform—then {{{libpqxx}}} is the library you use.  It is the standard C++ language binding for the postgres RDBMS.
    7 The source code for {{{libpqxx}}} is available under the BSD license, so you're free to [wiki:DownloadPage download it], pass it on to others, change it, sell it, include it in your own code, and share your changes with anyone you choose.  No charge, no catch.  Also, no guarantees.
     7The source code for {{{libpqxx}}} is available under the BSD license, so you're free to [wiki:DownloadPage download it], pass it on to others, change it, sell it, include it in your own code, and share your changes with anyone you choose.  No charge, no catch.  Also, no guarantees.  :-)
    1010= News =
     12== 2019-04-28: Breaking compatibility for 7.0 ==
     14Work on 7.0 has begun.
     16Before we can build the new features, we'll tear down a few deprecated ones.  The "table streams" —`tablereader` and `tablewriter`— are first to go: they have been replaced by `stream_from` and `stream_to`.
     18I'm still experimenting with the new connection reactivation landscape.  The feature will not be gone completely, but it will change.  The burden for ensuring that a connection is active will come to lie with the application.  I don't think it will be a lot of work, but it will simplify the library and remove a complication.  I don't like complications.  If you're like me, you'd rather understand exactly what your application does than save a few function calls.  It will also make libpqxx a little lighter and faster.
    1221== 2019-03-19: Bug in result objects outliving their connection objects ==
    2635It's still a nasty complication though, and if you have any clever ideas on how to improve the situation, please file a bug on our Github page!
    29 == 2019-02-02: 6.3.0 released ==
    31 Greetings from FOSDEM.  After a lot of changes, 6.3.0 has now been tagged and announced.  See below for the changes, and directions for the future.
    34 == 2019-03-19: Recent changes ==
    36 Thanks to some major contributions from Joseph "!JadeMatrix" Durel in 6.3.0, we now have:
    38 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.
    40 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.
    42 In other news:
    43  * 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.
    44  * The CMake build has been overhauled.  There may be teething problems, so please report anything you run into.
    45  * Copying `result` objects for long SQL queries is now faster.
    47 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.
    49 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.  At some point those features really will disappear.
    52 == 2019-03-19: Preparing for 7.0 ==
    54 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.
    57 === C++ upgrade ===
    59 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?
    61 The C++17 features I'd particularly like to use are:
    62  * `std::optional` as the one standard way to accommodate null values.
    63  * Nested namespaces.  It'll make `pqxx::internal` easier for me to manage.
    64  * `std::string_view` will replace a lot of `std::string`.
    65  * `std::to_chars` and `std::from_chars` will replace `a lot` of libpqxx code.
    67 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.
    70 === Connection classes ===
    72 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, a type-safe destructor, and a much easier class hierarchy to work with.
    74 The plan is to fold 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.
    77 === Replacing lazyconnection and asyncconnection ===
    79 If you're using `lazyconnection` or `asyncconnection`, the API will change.  You'll have to do a bit of extra work.
    81 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.
    83 Is this a major problem for you?  Please let me know by filing a bug on the Github page before it's too late!