Fix behaviour of fetch() without any data with PostgreSQL#1330
Fix behaviour of fetch() without any data with PostgreSQL#1330vadz wants to merge 6 commits intoSOCI:masterfrom
Conversation
If execute() didn't bring any data from the server, all statement member variables remained uninitialized, resulting in problems (UB, infinite loops, ...) if fetch() is called later. Fix this by initializing numberOfRows_ and checking for it in fetch() and simply not doing anything there if it is 0. Closes SOCI#1328.
Same fix is required for MySQL as for PostgreSQL, see the previous commit message for explanation.
Ensure we don't try doing anything in fetch() if there is no data to retrieve.
Instead of calling throw_oracle_soci_error(), add oracle_soci_error ctor taking the parameters that were passed to this function and just throw the object created using this ctor. This is more explicit and simpler. No real changes.
Check for the error apparently triggered by trying to execute a statement without any results and do not turn it into exception.
Remove ugly get_error_details() function taking multiple output parameters and just create oracle_soci_error objects directly. As error.h has now become useless, remove it too.
343c4d1 to
9b03708
Compare
|
Yes, the random number reads in fetch are (or at least seem to be :) ) fixed by this. Thank you!
How should I have approached writing a "generic" interface for queries with SOCI, e.g. an interactive tool to execute requests and view their results without knowing in advance if the query returns any data or not? Or was this indeed the only way to do it without parsing the requests manually beforehand? P.S.
I'm... not really sure. I guess that might be just UB justifying the "undefined" in its name, because even with everything but that query commented I still get I wanted to try with the clang's memory sanitizer because I expected the UB sanitizer to report an undefined memory read and... it threw a |
If execute() didn't bring any data from the server, all statement member variables remained uninitialized, resulting in problems (UB, infinite loops, ...) if fetch() is called later.
Fix this by initializing numberOfRows_ and checking for it in fetch() and simply not doing anything there if it is 0.
Closes #1328.