Hi Norbert, > OK, but you don't gain much because this is only one malloc you will > save. One more is needed for the auxiliary data and I think several are > done by the native client libraries. The reason I opted against this was > the choices you have to care about when you a) get an already > initialized structure and b) get a structure that only seem to be > initialized due to random data.
The mallocs in the native client libraries are unavoidable, my point was just to minimize their use since each one involves a lot of overhead. I did not get the point about initialized data. Is there a difference between stack and heap? > Many native database libraries support prepared statements. It's > relatively simple: > - Send the SQL with markers to the server and get back a handle > - bind your values to this handle > - Send only the data to the server (one or several times) > - Get the binary values from the result set > Contrary to e.g. DBI I would favour a single function that copies the > data to a memory area provided by the client. This can be used with all > types of data and is faster and safer than allocating memory that must > be freed by the client. I agree on this. The design I had in mind was more minimalistic such as not to involve any memory allocation (except on stack): odbx_prepare(conn_obj, query_obj, statement); // The statement contains markers like %s or %i which are replaced by native client library markers odbx_exec_prepared(conn_obj, query_obj, result_obj, ...); // The variadic arguments are interpreted according to the types known from the previous function and stored in query_obj > No, as this would interfere with the positive return values for e.g. > odbx_result(). Misunderstanding, I meant to return values other than errors (In-band error codes, which are dangerous https://www.securecoding.cert.org/confluence/display/seccode/ERR02-C.+Avoid+in-band+error+indicators ). The negative error codes design would allow this practice to be used in other functions than odbx_result. Instead, ODBX_RES_ROWS and NOROWS could be removed in favour of a mean to get the number of rows after a SELECT. ODBX_RES_TIMEOUT in turn could be included as an error code. > The initial design decision was to allow having multiple result sets per > connection even if most databases doesn't support this. But I didn't > want to limit the client libraries that would be able to so even if none > of the currently implemented ones can do so :-) Misunderstanding, I meant to call odbx_field_value( handle, result, i ) rather than odbx_field_value( result, i ). The user might think that he can free the connection and then still read the result structure. Including the handle in all functions might however be excessive, so you could simply replace odbx_result_finish(result) by odbx_result_finish(handle, result). Thus, users have to keep the handle alive while parsing the result structure. Regards, Thibault ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ libopendbx-devel mailing list libopendbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopendbx-devel http://www.linuxnetworks.de/doc/index.php/OpenDBX ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ libopendbx-devel mailing list libopendbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopendbx-devel http://www.linuxnetworks.de/doc/index.php/OpenDBX
