VZ

> 1. Because the old code does not offer the needed functionality? Sorry, but I am a bit confused by your comment. Are you referring to a specific part of...

I hope to merge #996 soon, so using `std::uint8_t` shouldn't be a problem. I'm a bit worried about the state of Oracle, as it's the most idiosyncratic backend and it...

> In constrast, with this PR, this works for all backends that support BLOBs, except for Oracle. But how does it work for Oracle? I mean, it must be possible...

> You need to select the blob from your DB. Are you absolutely certain about this? I didn't check it, but this just seems so weird to have to do...

I'm not sure, it looks like there is some existing code using blobs without transactions around them, e.g. here is a [random example](https://cs.github.com/BelledonneCommunications/liblinphone/blob/8d0e9ebf5028fa7cf58ca8c71e9d350f1e0d997f/src/db/main-db.cpp#L4143) I found. Is the need for a...

> In terms of unifying the BLOB test-cases: Is there some mechanism in SOCI to abstract differences in SQL type specification for different backends? In the tests, there is `test_context_base`...

> What about the Oracle situation? Do you want me to remove the (potential) optimization of opening the BLOBs in favor of not requiring a transaction? It would be really...

> > a good plan might be to introduce a new API working only inside a transaction > > How would that look like? Creating a new `soci::blob2` object that...

> > but rather at PostgreSQL level directly > > Then we would have to rewrite the backend-specific transaction handling as well as currently they don't appear to use some...

Thanks for the report and the workaround. The real solution is to upgrade to a non-ancient version of CATCH which has probably fixed this already, but this won't happen in...